


Institutional Archive of the Naval Postgraduate School 


Calhoun: The NPS Institutional Archive 
DSpace Repository 


Theses and Dissertations 1. Thesis and Dissertation Collection, all items 


1997-12 


Non-standard requisitioning process 
improvement : cost and benefit analysis of 
implementing the Automated Non-standard 
Requisitioning System (ANSRS) within 
Submarine Forces, Pacific (SUBPAC) 


Santacroce, Mark 


Monterey, California. Naval Postgraduate School 


http://ndl.handle.net/10945/8741 


Downloaded from NPS Archive: Calhoun 


Calhoun is the Naval Postgraduate School's public access digital repository for 


(8 D U DLEY research materials and institutional publications created by the NPS community. 
citth Sirah Calhoun is named for Professor of Mathematics Guy K. Calhoun, NPS's first 


INN | KNOX appointed —- and published — scholarly author. 

i LIBRARY Dudley Knox Library / Naval Postgraduate School 

411 Dyer Road / 1 University Circle 
Monterey, California USA 93943 





http://www.nps.edu/library 





NPS ARCHIVE 
1997.12 
SANTACROCE, M. 


NAVAL POSTGRADUATE SCHOOL 


Monterey, California 





THESIS 


NON-STANDARD REQUISITIONING 
PROCESS IMPROVEMENT: COST AND 
BENEFIT ANALYSIS OF IMPLEMENTING 
THE AUTOMATED NON-STANDARD 
REQUISITIONING SYSTEM (ANSRS) WITHIN 
SUBMARINE FORCES, PACIFIC (SUBPAC) 


by 
Mark Santacroce 


December, 1997 


Principal Advisor: Jane N. Fertler 
Associate Advisor: Kevin R. Gue 


- Thesis 
S16625 





Approved for public release; distribution is unlimited. 


DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 93943-5101 





REPORT DOCUMENTATION PAGE 7 | Form omrad OMB No. 0704-0188 


— 


} Public reporting burden for this collection of mformation 1s estimated to average | hour per response, including the tume for reviewing instruction, searching existing data sources, 

| gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this 

| collection of information, wcluding suggestions for reducing this burdva, to Warchington dleadquartors fervices, Dircetorate for bnfunuetion Uperstions and x cports, 1215 Sotlevsun 
| Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington DC 20503. 


AGENCY USE ONLY (Leave blank) REPORT DATE 3. REPORT TYPE AND DATES COVERED 
December 1997 Master’s Thesis 

TITLE AND SUBTITLE Nonstandard Requisitioning Process Improvement: Cost |5. | FUNDING NUMBERS 

and Benefit Analysis of Implementing the Automated Non-Standard 
Requisitioning System (ANSRS) Within Submarine Forces, Pacific 
(SUBPAC) 
AUTHOR(S) Mark Santacroce 


7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING 
Naval Postgraduate School ORGANIZATION 















Monterey CA 93943-5000 REPORT NUMBER 


9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONTTORING 
AGENCY REPORT NUMBER 






11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the 
official policy or position of the Department of Defense or the U.S. Government. 


12a. DISTRIBUTION/AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE 
Approved for public release; distribution is unlimited. 


13. ABSTRACT (maximum 200 words) — 

This research evaluates the Automated Non-Standard Requisitioning System (ANSRS) to determine the feasibility 
\of implementing this technology as a replacement to the manual nonstandard procurement processes currently 
employed within Submarine Forces, Pacific (SUBPAC). Manual nonstandard procurement processes for both 
_surface ships and submarines, as well as the prototype ANSRS process implemented on several surface ships and| 

shore commands, are discussed, diagrammed, and quantified. These processes are then compared and contrasted, | 

and the appropriate conclusions are derived. | 
The primary conclusion is that ANSRS should be implemented within SUBPAC, contingent upon the| 
resolution of several significant problems. 


= a 


14. SUBJECT TERMS ANSRS, Nonstandard Requisitioning, Submarines 15. NUMBER OF 
PAGES 105 
16. PRICE CODE | 
> ; ee — en ee eZ f 7 a ae 
Per SELCUREY CLASSIFL 18. SECURITY CLASSIFI- 119. SECURITY CLASSIFICA- | 20. LIMITATION OF | 
CATION OF REPORT CATION OF THIS PAGE TION OF ABSTRACT ABSTRACT 
Unclassified Unclassified Unclassified UL 





NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89) 
Prescribed by ANSI Std. 239-18 298-102 





Approved for public release; distribution is unlimited. 


NON-STANDARD REQUISITIONING PROCESS IMPROVEMENT: COST 
AND BENEFIT ANALYSIS OF IMPLEMENTING THE AUTOMATED 
NON-STANDARD REQUISITIONING SYSTEM (ANSRS) WITHIN 
SUBMARINE FORCES, PACIFIC (SUBPAC) 


Mark Santacroce 
Lieutenant Commander, United States Navy 


B.B.A., Southwest Texas State University, 1985 


Submitted in partial fulfillment 
of the requirements for the degree of 


MASTER OF SCIENCE IN MANAGEMENT 
from the 


NAVAL POSTGRADUATE SCHOOL 
December 1997 





DUDLEY KNOX LIBRARY 
NAVAL POSTGRADUATE SCHOOL 
MONTEREY CA 93943-5101 


ABSTRACT 


This research evaluates the Automated Non-Standard Requisitioning System 
(ANSRS) to determine the feasibility of implementing this technology as a 
replacement to the manual nonstandard procurement processes currently employed 
within Submarine Forces, Pacific (SUBPAC). Manual nonstandard procurement 
processes for both surface ships and submarines, as well as the prototype ANSRS 
process implemented on several surface ships and shore commands, are discussed, 
diagrammed, and quantified. These processes are then compared and contrasted, and 
appropriate conclusions are derived. 

The primary conclusion is that ANSRS should be implemented within SUBPAC, 


contingent upon the resolution of several significant problems. 
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I. INTRODUCTION 

The purpose of this thesis is to evaluate the functionality and cost of the 
Automated Non-Standard Requisitioning System (ANSRS) program. It will be evaluated 
in the context of fleet usage and its application in the submarine community. The dual 
goals of shifting to a paperless environment and reducing costs have led to the 
development of automated processing procurement technology such as ANSRS; 
improvements in readiness are meant to be a byproduct of implementation. This chapter 
provides background information on the driving forces behind the ANSRS program. 
Additionally, the objective, scope, methodology, and organization of this study are 
described. 
A. BACKGROUND 

In response to the Government Performance and Results Act (GPRA)' and the 
most recent Quadrennial Defense Review (QDR), the Secretary of Defense directed a new 
strategic approach to the management and operation of national defense efforts [Refs. 1 
and 2]. The Department of Defense (DoD) Logistics Strategic Plans (LSP) for fiscal years 
1995 and 1998 delineate the framework for implementing the new strategic approach 
[Refs. 3 and 4]. The evolution of the ANSRS program can be directly matched to several 
of the 1998 LSP’s Fundamental Principles and Logistics Management Imperatives. 


These include: 


Fundamental Principles 
1. Logistics organizations should be streamlined and consolidated 


whenever possible, and unneeded, uneconomical or redundant logistics 
process segments, cycles, nodes and layers should be reduced or 
eliminated; 


'PL. 103-62 


2. Access to accurate and timely logistics information should be provided 
to all customers; and 

3. Performance should be measured based on improvement of customer 
support and reducing total logistics costs. 


Logistics Management Imperatives 
1. Reengineer business practices to increase efficiency and reduce logistics 


resource requirements; 

2. Reduce logistics cycle and response times; 

3. Effectively employ new technologies to improve performance and 
reduce costs; and 

4. Improve the effectiveness of the logistics workforce. 

Although many of the Navy’s supply processes have been automated over the 
years, the purchase of nonstandard inventory and the nonstandard procurement process 
remains bound in a manual, paper environment. During visits to ashore and afloat 
activities to ascertain their need for more expedient technical screening and requisition 
submission methods, file drawers full of old paperwork were discovered. Cumbersome 
technical manuals, drawings, and microfiche libraries were still being used to screen 
requirements. Afloat, technical screeners were not able to share data, creating 
redundancies and resulting in excessive requisition processing time (RPT) and requisition 
submission time (RST). Ashore, Fleet and Industrial Supply Centers (FISCs) acted as 
independent, stand-alone regional providers of next-level procurement services [Ref. 5]. 
Frequently, information provided from the end-user activity to the FISC was incomplete 
or required further clarification; the inability of the FISCs and end-users to easily 
communicate and correct paperwork deficiencies often resulted in substantial delays in 
contracting for the needed material and excessive logistics response time (LRT). 


The Naval Supply Systems Command (NAVSUP), in its continuing efforts to 


reduce costs of operations through standardization, centralization, and downsizing, and to 


consolidate the entire nonstandard procurement process at the Navy Inventory Control 
Point Mechanicsburg (NAVICP-M), developed a PC-based software package, ANSRS. 
Customer Support Modules at each end-user activity, Procurement Activity Modules at 
each FISC procurement site, and the Central Database Module (CDB), or Host Module at 
the Central Technical Activity (CTA),” are linked via electronic data interchange (EDI) 
methods designed to provide a paperless, streamlined communication network . 
B. OBJECTIVE 

The objective of this study is to determine the feasibility of implementing ANSRS 
technology as a replacement to manual nonstandard procurement processes currently used 
within Submarine Forces, Pacific (SUBPAC). 
ce. SCOPE 

In this study, five areas are examined: 1) current technologies and processes 
relevant to ANSRS development and ANSRS efficacy; 2) ANSRS technology and 
program objectives, 3) manual nonstandard procurement processes, both afloat and 
ashore; 4) measures of effectiveness; and 5) performance of the ANSRS prototype 
onboard surface ships and at shore procurement activities. The first and second areas 
focus on the past and provide the reader relevant background information. The final three 
areas present the data supporting the conclusions and recommendations pertinent to the 
objective of this study. 

The ANSRS program is still in the introduction and testing phase of its life cycle. 
This circumstance has limited the research of this study; how well the ANSRS program 


integrates and will integrate with other DoD and Navy logistics improvement initiatives 1s, 


* NAVICP-M (Code 054), Data Integrity Division 


at this point, in the realm of educated speculation. This research, unless otherwise noted, 
assumes that the ANSRS program will not adversely affect other logistics improvement 
initiatives currently underway. 
BD METHODOLOGY 

This study began with research into the literature associated with the ANSRS 
program and its claim to improve the manual nonstandard procurement process. 
NAVSUP and NAVICP-M personnel were interviewed to appraise and report ANSRS 
program objectives and expected benefits. The prototype Afloat Customer [Support] 
Module was used to research and simulate the end-user’s experience with ANSRS. The 
manual nonstandard requisitioning process, from the perspective of the submarine end- 
uSer, was ascertained through interviews with supply personnel from USS KEY WEST 
(SSN 722), homeported in Pearl Harbor, Hawan and by “walking through” requirements 
from the end-user to the Submarine Logistics Support Center, Pearl Harbor Detachment 
: “USC-PH) to FISC Pearl Harbor (FISC-PH). Interviews were conducted with FISC 
personnel to identify the problems and choke points currently experienced with the 
ANSRS process, and to document the perceived benefits and/or deficiencies associated 
with ANSRS implementation. SUBPAC personnel, including the Force Supply Officer 
and Force Storekeeper, were interviewed to ascertain perspectives and identify concerns 
with the ANSRS program and its future usefulness to readiness improvement. The 
perspectives of non-SUBPAC, ANSRS-capable activities were ascertained through 
interviews and questionnaires. Alternative or hybrid nonstandard procurement method 


Studies were reviewed. A literature search of internet resources was also conducted. 


E. ORGANIZATION OF STUDY 

The remaining chapters in this thesis are organized as follows: Chapter II provides 
a literature review and theoretical framework for this study. Chapter III orients the reader 
to ANSRS implementation background issues and a comparison of the manual and 
ANSRS procurement process flows. Chapter IV presents, analyzes, and provides 
interpretations of the data. Chapter V presents conclusions and recommendations relevant 


to the objective of this study. 





I. LITERATURE REVIEW AND THEORETICAL FRAMEWORK 

This chapter introduces the reader to the literature requisite to understand both the 
theoretical framework and the remaining discourse of this study. The theoretical 
framework of this study 1s centered around two elements of the manual nonstandard 
procurement process: Procurement Cycle Time—defined as the interval between the 
moment the end-user identifies a material or service need to the moment the contract for 
that need is awarded—and related costs. The two are not unrelated; even in the Navy, 
time is money. The Navy’s modus operandi for reducing Cycle Time and costs associated 
with the nonstandard procurement process, via the ANSRS program, is also an important 
theoretical issue. The flow of the current manual procurement process is briefly 
presented. A more detailed presentation of the manual procurement process will be 
discussed, diagrammed, and quantified in Chapter HI, as will the ANSRS flow for surface 
ships and FISCs. 
A. NONSTANDARD MATERIAL 

jl Definitions 

Nonstandard materials are simply those items of supply that are not centrally 
managed or procured for supply system stock. Conversely, items that are centrally 
managed or procured for supply system stock are known as “standard” material, assigned 
a National Stock Number (NSN), and managed in accordance with federal law and the 
precepts of the Federal Catalog System. ANSRS deals solely with nonstandard items but 


can also be used for technical screening of standard items. 


a. “Traditional” Nonstandard Material 

The NAVSUP P-485 lists categories of items exempt from the Federal 
Catalog System, such as items procured on a one-time basis and items intended solely for 
local use or consumption [Ref. 6]. Examples include equipage, such as facsimile 
machines, and some habitability improvement material, such as certain types of floor tile 
and paint. Major equipment, repairable components, and “throw away” repair parts are 
generally assigned an NSN. However, it is not always readily apparent whether a 
particular item is, or has, an acceptable substitute assigned an NSN. Since the current 
hierarchy of mandatory sources of supply generally dictates ordering standard material 
before resorting to open procurement, it 1s imperative to screen one’s requirements against 
available Federal Catalog System databases such as FEDLOG, HAYSTACK, or 
PARTSMASTER.” 

b. Commercial Off The Shelf (COTS)/Non-Developmental Item 

(NDI) and CANDI 

As a result of the Federal Acquisition Reform Act of 1996", and in an effort 
to substantially reduce equipment developmental and life cycle support costs, Hardware 
Systems Commands (HSC) are increasingly seeking ways to exploit COTS and NDI 
technologies [Ref. 7]. COTS and NDI both refer to previously developed items; the main 
difference is that COTS technologies are developed in the private sector and usually have 
commercial applications whereas NDI technologies are developed within the government 
and usually have no commercial applications. However, there are examples of COTS 
2 PEDLOG is commuanlsoieed Ieete ett the fleet, including submarines and ships. HAYSTACK ane 


PARTSMASTER are typically available only at larger technical screening activities. 
*P.L. 104-106 


technologies developed solely for government use and NDI technologies having 
commercial applications. Therefore, the encompassing term “CCANDI,” which stands for 
COTS and Non-Developmental Item, is often instead used, and will be used in this study. 
There are two “types” of CANDI: HSC directed and Fleet directed. 

2: Nonstandard Material Requirement Determination 

A requirement that is identified as nonstandard (i.e., without an assigned NSN) can 
normally be procured through one of three types of open purchase methods. Various 
regulations, particularly NAVSUP Instruction 4200.85C, which incorporates pertinent 
aspects of the Federal Acquisition Regulation (FAR) and the DoD Federal Acquisition 
Regulation Supplement (DFARS) for simplified pest procedures and credit card 
purchases (see paragraph A3b and c below), allow open procurement of standard material 
or waiver of mandatory sources of supply in some cases [Ref. 8]. Here, too, it is 
imperative that one be able to screen one’s requirements accurately. ANSRS provides the 
end-user the capability to access various types of reference material online, including 
acquisition regulations. 

3: Nonstandard Material Procurement Methods 

It is important to note that all of the end-users of this study, both those that 
currently have ANSRS implemented within their command and those in the submarine 
community, use funds derived from a congressional appropriation entitled Operations and 
Maintenance, Navy (O&MN) to procure supplies and services. End-user commands may 
use Other appropriated (and non-appropriated) funds for such things as subsistence and 
expensive computer systems. Although ANSRS deals with all monetary amounts and 


other appropriation types used to procure material and services, the discussion in the 


remainder of this chapter applies exclusively to procurements using O&MN funds. 

a. Large Purchases 

Large purchases are procurements that exceed the simplified acquisition 
threshold of $100,000, or $200,000 for contingency requirements outside of the United 
Stated [Ref. 8]. Additionally, O&MN funds cannot be used for minor construction 
projects in excess of $500,000. 

b, Small Purchases Without a Credit Card 

Procurements that do not exceed the simplified acquisition procedures 
thresholds above are commonly called “small purchases” or “simplified purchases” and, as 
implied, are governed by less stringent acquisition regulations than are large purchases. 
However, unless the contracting office making the purchase has been FACNET certified, 
small purchases cannot exceed $50,000 [Ref. 8].” 

ie Small Purchases With a Credit Card 

A procurement of authorized supplies and services, the aggregate amount 
of which does not exceed $2,500, is known as a “micro-purchase.” In accordance with 
the National Performance Review of 1993, credit cards are to be used for micro-purchases 
[Ref. 9]. There are, however, certain restrictions to using credit cards; for example, credit 
cards cannot be used to procure hazardous materials, or services of any type [Ref. 8]. The 


main advantage of a micro-purchase is that a contract can be awarded without soliciting 


> The Federal A __ isition Computer Network (FACNET) is the government-wide systems architecture for 
the acquisition © upplies and services. It provides for electronic data interchange (EDI) of acquisition 
information between the government and the private sector, employs nationally and internationally 
recognized data formats, and provides universal user access. FACNET certification requires that more 
than 75 percent of an agency’s small purchases exceeding $2.500 be made via FACNET. See FAR 4.504 
and Ref. 8 for complete certification requirements. 
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competitive quotations, as long as the contracting officer determines that the price is 
reasonable. The advantages of using the credit card are a streamlined (and, currently, a 
less expensive) payment procedure and a reduction in paperwork requirements. These 
advantages save time. NAVICP-M data indicates that approximately 80 percent of all 
purchases are micro-purchases and, unless restricted, are eligible for procurement with a 
credit card. 

B. CYCLE TIME 

The term “Cycle Time” will be used in this study and, as such, is defined as the 
interval between the moment the end-user identifies a material or service need to the 
moment the contract for that need is awarded. \n this study, Cycle Time does not include 
manufacturing lead times and shipment/transportation times because ANSRS is not 
designed to automate those actions. Cycle Time is broken down into the following three 
segments: 

Ih, Requisition Preparation Time (RPT) 

RPT is the interval between the moment the end-user identifies a need to the 
moment when the procurement document is completed onboard the ship or submarine. 
RPT activities include conducting initial research, ordering, preparing the procurement 
document, conducting technical screening, obtaining requisite approvals, and assigning a 
requisition number. 

2: Requisition Submission Time (RST) 

RST is the interval between the moment when the procurement documented 1s 
completed onboard the ship or submarine to the moment the document is accepted by the 


procurement activity. “Acceptance” does not occur until the procurement activity is 
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satisfied with the accuracy of the procurement document. Therefore, if the procurement 
activity returns a previously delivered procurement document to the ship or submarine 
because of inaccurate or missing information, the resultant delay is part of RST. 

ce Procurement Administrative Lead Time (PALT) 

PALT is the interval between the moment the procurement document is accepted 
at the procurement activity to the moment the contract is awarded (1.e., the amount of 
time it takes a buyer to make a buy). PALT standards vary among different procurement 


activities, even those at the same level such as FISCs. 


Cr EC/EDI 
Ie Definitions 
a. Electronic Commerce (EC) 


EC 1s the paperless exchange of business information using Electronic Data 
Interchange (EDI), electronic mail (e-mail), computer bulletin boards, FAX, electronic 
funds transfer (EFT), and other similar technologies [Ref. 10]. 

b. Electronic Data Interchange (EDI) 

EDI is the computer-to-computer exchange of business information using a 
public standard such as ANSI-X12 or EDIFACT.® EDI is a central part of EC, because it 
enables businesses to electronically exchange business information faster, cheaper, and 
more accurately than is possible using paper-based systems [Ref. 10]. ANSRS 


incorporates EDI in its program capabilities. 


° See Ref. 9, Chapter 7 for American National Standards Institute (ANSI) standards. conventions. and 
formats. U.S. Government agencies use the ANSI X12 format. EDIFACT is used internationally and is 
the United Nations standard. 
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ae Origins of EDI 

EDI was first used in the transportation industry more than 20 years ago by 
ocean, motor, air, and rail carriers and associated shippers, brokers, customs, freight 
forwarders, and bankers. The first set of industry EDI standards were developed by the 
Transportation Data Coordinating Committee (TDCC) and consisted of 45 transaction 
sets for the transportation industry. ANSI X12 standards were developed later and are 
based upon the TDCC syntax and format. More than 50,000 private-sector companies in 
the United States currently use EDI. Many more use it internationally [Ref. 10]. 

oS: Benefits of EDI 

As discussed in the first paragraph of this study, shifting to a paperless 
environment and reducing costs are the dual goals of automating the nonstandard material 
procurement process. The stated benefits of EDI dovetail with these goals. Those 
benefits are [Ref. 10]: 

1. Improvements in overall quality through better record-keeping, fewer 
data errors, reduced processing time, and less reliance on human 
interpretation of data; 

2. Lower mailing costs will be realized through reduced postage and other 
mailing costs and elimination of lost documents; 

3. Reduced order time and less paperwork; 

4. Faster billing. Since orders are processed sooner, billing and closeout 
can occur sooner; and 

5. Better information for management decision making, including more 
accurate audit trails. 

4, Federal Acquisition Streamlining Act (FASA) of 1994’ 


FASA was enacted to simplify and streamline the federal procurement process. 


Intended to significantly change how the Government does business, FASA repealed or 


™PL. 103-355 


ips 


substantially modified more than 225 provisions of the law to reduce paperwork burdens, 
facilitate the procurement of commercial products, enhance the use of 

simplified procedures for small purchases, transform the procurement process to 
Electronic Commerce, and improve the efficiency of the laws governing the procurement 
of goods and services. The most significant provisions of FASA include [Ref. 10]: 


1. Emphasizing the procurement of commercial products; 
Streamlining procurement procedures under an elevated small purchase 
threshold (see paragraph A3a above for current thresholds); 

3. Implementing FACNET; 

Establishing uniformity in the procurement system; and 

5. Improving protest and oversight processes and authorizing specific 
pilot programs 
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=; Commercial Software Packages 

There are a number of commercially available software procurement packages that 
profess a high degree of adaptability and flexibility.* All of those reviewed by the author 
are Windows-based and appear to be modifiable to conform with Navy-specific automated 
nonstandard material purchasing requirements. However, commercial software packages 
were not considered by NAVSUP because the complexities of the tasking, file interface 
requirements, and the operating environment were judged to be too unique for any 
CANDI program to fully adapt/accommodate [Ref. 11]. 
D. ANSRS 

1. Introduction 

Informal research conducted by NAVSUP 41 and the NAVSUP ANSRS Program 
Manager for FY94-96 estimated that 5-6% (~ 440,000) of all requisitions submitted by all 


Navy activities were for nonstandard material [Ref. 11]. It was intended to determine, in a 


® The author reviewed six commercial software brochures. 
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general sense, whether automating nonstandard material procurement processes was a 
worthwhile objective to pursue. Standard material counts were derived from both 
NAVICPs whereas nonstandard counts were derived from FISCs. Manually processing 
such a large number of requisitions requires a great deal of resources, in terms of labor, 
paper, time, and money, and presented an ideal opportunity to effect cost savings and 
eliminate inefficiencies through automation. Therefore, in late May 1995, NAVSUP 04 
directed the development of a system to automate the processing of nonstandard 
procurements and record results of technical screening actions, to be delivered by April 
01, 1996. Along with the functional and operational complexities discussed in paragraph 
C5, and the desire to combine and standardize similar but separate efforts then underway 
to automate nonstandard procurement and modernize technical screening research tools, 
this time frame constraint precluded any serious consideration of commercially available 
software packages [Ref. 11]. Instead, under NAVSUP guidance and CTA control, 
programmers from the Fleet Material Support Office (FMSO) merged the full 
functionalities of two ANSRS precursors, TSES and SPEED. 

Ze Precursors to ANSRS 

a. Technical Screening Expert System (TSES) 

TSES incorporated most functionalities of the envisioned automated 
nonstandard procurement system and was therefore designated to form the core program, 
to which other required functions would be added. Developed at NAVICP-M, TSES 
provided a technical screening function which focused on the identification of hazardous 


material (HAZMAT) substitutes and compliance with U.S. laws and international treaties 
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concerning HAZMAT, ozone-depleting substances, and plastics disposal. Appendix A 
lists TSES capabilities [Ref. 13]. 
b. Standard Processing Environment for Electronic Documents 
(SPEED) 

Developed at FISC Oakland, SPEED is mainly a vehicle for nonstandard 
requisition transmission and status update reception. SPEED is capable of transmitting 
completed work to the Automated Procurement and Accounting Data Entry (APADE) 
system, the FISCs’ system for contracting. Appendix B lists SPEED capabilities [Ref 
13]. 

c. APADE Off Line (AOL) 

As noted earlier, the full functionalities of TSES and SPEED were 
retained. The functionalities of AOL, however, were not considered because AOL 
requires the afloat end-user to learn the file structure and submission procedures for 
APADE. This requirement is counter to NAVSUP’s strategic goal of reducing workload 
afloat [Ref. 11]. 

3. Program Description 
NAVSUP’s ANSRS Information Pamphlet describes the ANSRS program as 
follows [Ref. 5]: 

ANSRS 1s an automated (paperless environment) program which 
performs a basic-level technical review (customer level) of each 
requirement, generates an electronic requisition, downloads [the] 
requisition via the Streamlined Alternative Logistics Transmission System 
(SALTS) and forwards it to the CTA/FISC. ANSRS automatically screens 
incoming electronic requisitions. Validations and edits are built into the 
system and communication between all participants occurs via 


SALTS/EDI, and Military Standard Transaction Requisitioning and Issue 
Procedures (MILSTRIP) via Uniform Inventory Control Program 
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(UICP)/Uniform Automated Data Processing System (UADPS)/Shipboard 
Uniform Automated Data Processing System (SUADPS) transmissions, so 
as to maintain status and demand criteria. The system screens out 
exceptions and queues those items with inadequate data for manual review. 
As part of this process, ANSRS produces a database of all nonstandard 
requisitions, resident, maintained and updated at the CTA. A tailored 
version will be distributed via CD-ROM as part of the Customer and 
FISC/Procurement modules. As records of new items are added to the 
CTA nonstandard database, providing historical data and past procurement 
history, the program will become more proficient at screening requisitions, 
expediting technical screening of subsequent requisitions for same or 
similar items. Savings with respect to purchase of hazardous materials and 
storage of these materials will be realized since each technical screener at 
the customer, FISC and CTA level will have access to technical 
information identifying these items and the methodology necessary to 
process them correctly. 

The centralization of the nonstandard requisitioning process at the CTA 
will create a central repository for data to allow collection or part- 
numbered information, visibility of all part-numbered buys and will 
facilitate faster and more efficient service to the customer. In the long-run, 
as ANSRS propagates and assimilates users, the cost of processing 
nonstandard buys will decrease and will ultimately drive down the total 
weapon system support costs. 


In other words, ANSRS provides varying degrees of technical screening capability 


at all levels, the ability to consolidate and analyze nonstandard procurement data at the 


CTA, and an EDI method for reciprocal communication between all parties. It does not, 


however, directly assist the requisitioning activity in influencing the manufacture, release, 


and shipment of their requirements subsequent to contract award. 


The ANSRS prototype is a DOS-based, menu-driven application, which can be 


loaded into a personal computer (PC). The prototype does not interface with any version 


of the afloat shipboard maintenance/supply/financial computer systems known as SNAP 


(Shipboard Non-tactical ADP Program), and therefore does not meet the precepts of R- 
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Supply and 1T21.” In January 1998, the CTA is scheduled to deliver a Windows NT 
version of ANSRS to the Navy Management Systems Support Office (NAVMASSO) for 
Technical Compatibility Testing (TCT) and, if it passes TCT, for inclusion on 
NAVMASSO’s Preferred Products List (PPL). The final shipboard version could be 
ready as early as April 1998 or as late as June 1998 [Refs. 11 and 12]. This version will 
interface with SNAP. Until November 1997, when it was removed, a Customer Support 
Module was available on the Internet, although it could not be used to actually procure 
material. 
4. Program Objectives and Benefits 
The following section provides a brief overview of some of the more salient 
benefits ANSRS is designed to provide to the end-user. The System, Customer Support 
Module, Procurement Activity Module, and Host Module objectives are listed in 
Appendix C [Ref. 13]. 
a. Integrated System 
For LAN-capable ships, the ANSRS program is installed throughout, down 
to the division end-user and/or Repair Parts Petty Officer (RPPO). The requirement can 
be developed by the end-user and submitted via the LAN for Supply Department review 
and approval by the Hazardous Material Officer, Department Head, Supply Officer, and/or 
the Commanding Officer as required, based on the requisition priority and/or the type of 


material or service required. 


° Relational Supply (R-Supply) generally refers to ADP systems that are capable of updating separate 
databases with a single data entry keystroke; all supply-related ADP equipment is connected into one 
system. Information Technology 21° Century (IT21) is an overall set of principles that state that all ADP 
equipment should be compatible. 
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b. Non-Standard Database (NSDB) 

The NSDB contains all of the requisitions submitted by ANSRS customers 
and procurements made by the procurement activities for all unique cage/part number 
relationships. It 1s maintained by the CTA at NAVICP-M. Once this data is in the file, 
and that combination is required again, all cage/part number data—as well as the 
requisitioner’s default data—are pre-loaded into the procurement document. Procurement 
history files are also attached to later facilitate the procurement. NSDB data updates are 
provided to all ANSRS installations on a regular basis via CD-ROM. 

C. Reduced Workload 

ANSRS automatically screens any requirement not resident within the 
NSDB for hazardous material identification and NSN substitutes. Additionally, ANSRS 
has hotkey connections to resident and non-resident reference resources, reducing the 
need to maintain separate paper/fiche/CD-ROM libraries. As more items are added to the 
NSDB, the requirement for additional technical screening and research will diminish. 
ANSRS also allows requisitions to be batch processed and transmitted. 

d. Enhanced LRT 

ANSRS will reduce LRT—the time interval between the date of the 
requisition and receipt of the requirement—as pre-transmission technical screening and 
document entry errors decrease, thereby decreasing the need for the procuring activity to 
request clarification and/or repeat technical screening. Additionally, transmitting to the 
procuring activity via EDI instead of physically walking through the requirement decreases 


the need for the procuring activity to manually re-enter procurement data into APADE. 
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Other LRT segments, such as manufacturer/vendor release time and shipping time, are not 
materially influenced by ANSRS. 
ide MANUAL PROCUREMENT PROCESS FLOW 

The manual procurement process onboard a surface ship or a submarine begins 
when the end-user identifies a nonstandard material or service requirement. It ends when 
the contract award, or buy, takes place (the time taken to complete this process 
determines Cycle Time). Subsequent, post-award actions taken on behalf of the 
requirement, such as requisition expediting, shipment/transportation, or receipt processing, 
are not considered part of the manual procurement process flow (nor Cycle Time) in this 
study because ANSRS does not automate those actions. 

i Surface Ship 

a. Process Without a Credit Card 
Once the nonstandard requirement is identified, the end-user orders the 

requirement on the shipboard maintenance/supply/financial computer, one of several 
versions of the SNAP system. The requirement will either be for a repair part (to repair an 
equipment) or for “consumable” materials or services (e.g., equipage, paint, vehicle 
rental). The latter are called money value only (MVO) requirements, which are often of a 
recurring nature and require less technical screening (an important point in this study). 
Repair parts are ordered under a pre-existing job (i.e., a defined maintenance action 
resident within SNAP); MVO requirements are ordered under a separate function. Next, 
the end-user prepares a procurement document by hand that provides the detailed 
information required by the Supply Department to perform technical screening and the 


procurement activity at the FISC to make the buy, usually a DD Form 1348-6 or DD 
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Form 1149 (Figures. 2.1 and 2.2). The document is administratively screened for format 
and content before being technically screened for NSN substitutes, HAZMAT compliance, 
and authorization for shipboard use. HAZMAT must be listed on the ship-tailored Ships 
Hazardous Materials List (SHML); otherwise, a SHML Feedback Report must be 
submitted to the Type Commander (TYCOM). The document then proceeds through an 
approval sequence that includes the end-user’s Department Head, the Supply Officer and, 
if hazardous (HAZMAT) or restricted material, the Hazardous Materials Officer and/or 
the Commanding Officer. The time taken to complete the above actions determines RPT. 
Finally, the signed paper document ts delivered to the FISC, where it undergoes another 
technical screening and is delivered to a buyer for award using a DD Form 1155 (Figure 
2.3). The time taken to complete these actions determines RST and PALT. At any point 
in this series of events, incomplete or unclear information will result in the return of the 
document to the end-user for correction and/or clarification. 

b. Process With a Credit Card 

The manual procurement process using a credit card is the same as that 
described above except that there is no need to deliver the document to the FISC. Once 
the required shipboard approvals have been received, the credit card holder can buy any 
authorized repair part or consumable material (services are prohibited) from the 
manufacturer/vendor. Contacts with the manufacturer/vendor can be done via phone, fax, 
email, or in person. Written internal operating procedures must be on file and the Supply 


Department must maintain a log of all buys [Ref. 8]. 
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2. Submarine 

The identification, ordering, procurement document preparation, and approval 
process for a submarine is the same as that of a surface ship. However, Supply Officers of 
submarines generally do not carry their own credit card and submit all of their nonstandard 
procurement requirements to the SLSC-PH."” Additionally, the vast majority of 
procurements onboard submarines are MVO requirements. Storekeepers (SK) assigned to 
USS KEY WEST (SSN 722) could not recall ever ordering a nonstandard repair part 
(although they knew how) [Ref. 14]. The SUBPAC Force Storekeeper recalled ordering 
only one nonstandard repair part in four years aboard his last submarine and, of the 
approximately 25 submarines he has inspected in his current position, has seen “very few” 
[Ret 15}. 

A short tangent is appropriate here to discuss the underlying causes of low 
nonstandard repair part procurements by submarines: configuration management and 
demand reporting. Configuration management basically consists of validating actual 
onboard equipment against those listed in the Weapons System File (WSF) located at 
NAVICP-M. Accurate configuration validation and reporting leads to accurate onboard 
NSN repair part support. Accurate and, importantly, complete demand reporting leads to 
more NSN assignments to nonstandard repair parts that are used with any frequency. If 
done properly, the above actions result in less reliance on nonstandard repair parts, 
although this situation could change in the future with an increased use of CANDI. 
SUBPAC submarines are able to attain a configuration accuracy in excess of 93 percent 


[Ref. 16] because they are able to devote the time necessary to conduct accurate 


© Some SUBLANT submarines maintain their own credit card whereas none do in SUBPAC as yet. 
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configuration management and are supported by a database that records almost all of their 
demands. 

Interposed between the submarine and FISC-PH is SLSC-PH.** Located 
in the same building as FISC-PH, the goals of SUSC-PH are to reduce the workload of the 
afloat submarine Supply Department and increase the submarine’s supply readiness. 
SLSC-PH logs the requirement, performs a procurement document accuracy check and an 
additional technical screen, then either makes the buy (for credit card purchases) or walks 
the document to the FISC buyer. After the buy is completed, all procurement data is input 
into the Integrated Submarine Information System (ISIS) for recording in the Submarine 
Logistics Data Base (SLDB), a centralized demand reporting database maintained at 
King’s Bay, Georgia [Ref. 17]. The time taken to deliver the document to SLSC-PH, and 
the processing time taken by SLSC-PH prior to making a credit card buy or the 
document’s acceptance at FISC-PH, are included in RST. 
F. CHAPTER SUMMARY 

The Navy classifies material into two categories: standard and nonstandard. 
Services are always “nonstandard.” If available, standard material must be procured 
before nonstandard sources can be contemplated. There are numerous rules and 
regulations governing the procurement of nonstandard materials and services. It is 
important for the end-user to understand when and how nonstandard material or services 
can be procured. This study uses the term “Cycle Time” to measure the interval between 
the time the end-user identifies a nonstandard requirement and the time the contract for 


that requirement is awarded. Cycle Time is broken down into three segments: RPT, RST, 


Viger ce AS ; : 
Similar activities service other submarine bases. 
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and PALT. EC/EDI methods are used to enhance the exchange of data. Legislation 
requires the use of these methods as a way to produce process efficiencies, and they play a 
key role in efforts to reduce Cycle Time. 

ANSRS was designed to automate and streamline the nonstandard procurement 
process. It evolved from several automated systems, principally TSES and SPEED. 
ANSRS provides the end-user with an integrated system that will reduce workload and 
reduce the time it takes to receive nonstandard material and services. This chapter closes 
with a broad presentation of the manual nonstandard procurement processes common to 
surface ships and submarines. Chapter III provides the reader more detail on the manual 


process and quantifies both the manual and ANSRS nonstandard procurement processes. 
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HI. PROCUREMENT AND ANSRS 
Unlike surface vessels, which have the ability to replenish stores at sea, and shore 
stations, which are fixed in place, submarines must receive all of their requirements before 
getting underway. This results in an urgency that has spurred the submarine community to 
invest in and develop logistics procedures generally considered superior to those employed 
by surface, air, and/or land-based fleet communities. Since the submarine community is 
somewhat logistically different, implementation of ANSRS within the submarine 
community may also be somewhat different. This chapter provides background on the 
limited implementation of ANSRS within the Navy and a brief overview of the ANSRS 
Afloat Customer Module (ACM) prototype. Additionally, the manual procurement 
process flow will be discussed, diagrammed, and quantified, as will the ANSRS 
procurement process flow for surface ships and FISCs. To date, ANSRS has not been 
implemented onboard any submarine. 
A, ANSRS IMPLEMENTATION 
1. Background 

a. Strategy 

The implementation strategy for the DOS-based ANSRS prototype initially 
called for installing a Procurement Activity Module at each FISC, and a Customer 
Support Module onboard two afloat customers of each FISC. The ongoing development 
of the Windows NT version has ended further installations until the newer version is 


completed. 
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b. Schedule 

The first prototype installations, at FISC Norfolk and onboard USS 
SAIPAN (LHA 2), were completed in March 1996. The last prototypes were installed in 
August 1997. Prototype versions are installed at 11 FISCs/FISC satellites, 14 ships 
(including two carriers), three Naval Air Stations (NAS), two Ship Repair Facilities 
(SRF), and two Fleet Activities (FLEACT). ANSRS 1s to be installed at all Navy 
customer activities, although the installation schedule has not been promulgated. See 
Appendix D for a list of sites implemented. 

2s Responsibilities 

a. Prototype Version 

In addition to assuming developmental responsibility for the ANSRS 
prototype, the CTA was responsible for its deployment to shore activities and prototype 
ships, including aircraft carners. The CTA is also responsible for evaluating ANSRS 
prototype performance [Ref. 12]. 

b. Windows NT Version 

Responsibility for deploying the Windows NT version of ANSRS to afloat 
units, including aircraft carriers, will belong to NAVMASSO, under the direction of 
NAVSUP 43. Shore activity implementation responsibilities will remain with the CTA 
[Refs. 1] and 12]. 

C. “ANSRS-Air” 

Although not assigned any implementation responsibilities, it is important 
to note here that, because of differing organizational responsibilities and capabilities, 


NAVICP Philadelphia (NAVICP-P) will retain the personnel responsible for the deep 
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technical screening (see next paragraph) and compilation of aviation-related nonstandard 
procurements. Procurement data will, however, be passed to NAVICP-M for inclusion in 
the NSDB. Although the NAVICPs may never combine personnel at one central location, 
ANSRS should eventually provide a single “face to the fleet” [Ref. 12]. 
d. Deep Technical Screening 
Deep technical screening refers to the process of validating nonstandard 
repair part procurements initiated by the end-user against the end-user activity’s Weapons 
System File (WSF) at either NAVICP-M or NAVICP-P. Results of deep screening could 
range from a) inclusion of the nonstandard repair part in the end-user’s Coordinated 
Shipboard Allowance List (COSAL), Aviation Consolidated Allowance List (AVCAL), 
Coordinated Shore Base Allowance List (COSBAL), or Shore Consolidated Allowance 
List (SHORCAL); to 5) triggering a complete validation check of the end-user’s 
equipment configuration. 
B. PROTOTYPE AFLOAT CUSTOMER MODULE 
I. Installation and Setup 
The ACM” consists of four 3.5 diskettes and requires 17.84 MB of hard drive 
space. It can operate in three types of PC environments: standalone, LAN Server, or 
LAN Workstation. Installation and setup were completed in less than 15 minutes. 
Installation instructions were easy to comprehend. Setup instructions were less explicit, 


but not overly complex. 
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Dr Operation 

After logging on to the ACM, the user can select a course of action from one of 
five menus: Requisition, Database, Approval, Security, and Help. Except for the Help 
menu, each menu consists of several functions.” There are additional “hotkey” functions 
used to access reference files, either resident in the computer’s hard drive or imported via 
disk. The ACM allows the user to either perform a technical screening or construct a 
procurement document. Technical screening was easy to accomplish; the logic paths were 
easy to follow and the sources were easy to access. The ACM is good at prompting the 
user for missing information required in the data tables. The menus were easy to 
understand and the ACM appears to incorporate the Customer Support Module objectives 
contained in Appendix C [Ref. 13]. 
C; MANUAL AND ANSRS PROCUREMENT PROCESS FLOWS 

In this section, manual and ANSRS procurement process flows are discussed and 
diagrammed using flow charts. Time is quantified to the greatest possible extent, given 
the organization and effectiveness of different activities, and presented as a value range. 
The ranges show approximate values that were derived from averaging questionnaire 
responses (see Appendix E) and data obtained via other means, such as interviews. 
Pertinent comments from interviews and questionnaire responses are include in the 
discussion as noted in brackets and /ifalics]. For convenience, relevant flow charts 


(Figures 3.1 through 3.5) are located at the end of this section. 


'* The Help menu, in the author’s view, is misnamed. It provides no help topic selections. but instead 
only the names of the software designers/programmers and some phone numbers to call for technical 
support. 
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is Manual Process Flow Through Surface Ship to FISC and Buyer 

The following manual procurement process flow discussions and depictions are 
derived from telephone interviews with Supply Department personnel assigned to various 
Naval Surface Forces Pacific (SURFPAC) ships, personal and telephone interviews with 
FISC personnel, through questionnaire responses, and the author’s eight years of 
experience aboard USS WHIPPLE (FF 1062), USS FIFE (DD 991) and as a SURFPAC 
staff officer. /Ships reported initiating 15 to 90 nonstandard procurements a month, or 
0.5 to 3 per day. Approximately 75 percent were credit card purchases for those 
commands using a credit card. Depending on the urgency and type of the requirement, 
RPT was completed in about one hour to over one day (see Table 3.1). Depending on the 
urgency of the requirement, method/type of procurement, and mode of delivery to the 
FISC (if not a credit card buy), RST/PALT took I hour to 25 days (see Table 3.2). Total 
Cycle Time ranged from about 2 hours to 26 days (see Table 3.3).] 

Some steps in the manual procurement process flow are conducted differently by 
separate ships although the same outcome is achieved. For instance, some ships require 
the end-user to order an MVO requirement in SNAP and fill out a procurement document 
before the SK will conduct technical screening. Others require only a locally developed 
worksheet that is used by the SK to conduct technical screening; it is the SK who inputs 
the MVO requirement into SNAP and fills out the procurement document. Sometimes the 
Commanding Officer will not sign a document until the Supply Officer does; usually, 
however, the Supply Officer signs last. Sometimes the SK walks the document to the 


FISC, sometimes the end-user does. Since it is impractical to depict all possible 
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variations, the methods most commonly employed by those included in the author’s 
research are discussed and diagrammed here. 

a. Manual Requisition Preparation Time (RPT) 

Manual RPT is diagrammed in Figure 3.1. RPT begins when the end-user 
identifies a requirement through initial research that may include technical manuals, 
drawings, microfiche/film/CD-ROM libraries, discussions with manufacturers or vendors, 
and personal records. The requirement will either be for repair parts (to repair an 
equipment) or for “consumable” material or services (e.g., equipage, paint, vehicle rental). 
The latter are called money value only (MVO) requirements. Ifthe requirement is for a 
repair part, the end-user will complete the following sequence of events: 1) open a 
maintenance job in SNAP (if none already exists); 2) search the equipment’s Allowance 
Parts List (APL) resident in SNAP for an NSN match if only the cage and part number are 
known; and 3) order the part in SNAP. If an MVO requirement, it is ordered through a 
different function in SNAP. No maintenance job is opened or needed. Either way, the 
end-user then manually prepares a procurement document and delivers it to an SK for 
technical screening. /Jnitial research for repair parts took from 15 to 60 minutes, 
depending on the library databases that needed to be searched and whether a 
manufacturer or vendor was contacted. Initial research for MVO requirements ranged 
from five minutes if of recurring nature to one hour if a manufacturer or vendor was 
contacted. Ordering a repair part in SNAP took from 30 to 45 minutes, most of which 
was spent opening the requisite job and conducting an APL search. Ordering MVO 
requirements took two to five minutes. Document preparation and delivery to the SK 


took from 10 to 30 minutes. ] 
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The SK first reviews the document for errors and completeness of required 
data. Ifthe requirement is for a repair part or consumable material the SK will check the 
FEDLOG to determine if there exists an NSN substitute and the SHML (and/or other 
databases) to determine if the material is hazardous or otherwise restricted. Requirements 
for services will be checked against regulations delineating authorized service 
procurements. This process is known as administrative and technical screening. 
[Administrative screening took one to two minutes. Technical screening took 15 to 60 
minutes, depending on whether a manufacturer or vendor was queried, whether the 
material was hazardous or restricted, etc. ] 

After the screening is completed, the end-user or SK walks the document 
through the Department Head, the Hazardous Material Officer (for HAZMAT), the 
Commanding Officer (for restricted materials and/or HAZMAT), and the Supply Officer. 
If the material is hazardous but not listed in the SHML, a SHML feedback report is 
submitted. After obtaining the requisite approvals, the document is returned to the SK 
who then changes the end-user’s SNAP-generated request number to a requisition 
number. After the requisition number is transcribed onto the document, the document is 
ready for delivery to the procurement activity. Failure to obtain the Commanding 
Officer’s signature for hazardous or restricted materials could result in the cancellation of 
the requirement. RPT is identical for credit card purchases. [Approvals took anywhere 
from 30 minutes to a day, depending on the nature of the requirement (e.g. HAZMAT) 
and the availability of the Department Head, Commanding Officer, etc. It took two to 


four minutes to assign a requisition number. ] 
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Duration 






Duration 
(repair parts) (MVO) 
15 min - | hr 

Order in SNAP 30 - 45 min 2-5 min 
l 


Prepare procurement document 
and deliver to SK 10 - 30 min 10 - 30 min 









Assign requisition number 2-4 min 


Total RPT 1.72 - 27.35 hrs 1.08 - 26.68 hrs 




















Table 3.1. Manual RPT for Ships 


b. Manual Requisition Submission Time (RST) and Manual 
Procurement Administrative Lead Time (PALT) 

Manual RST and manual PALT for procurement documents that are 
delivered to the procurement activity/FISC for award are diagrammed in Figure 3.2. RST 
and PALT for credit card buys is too simple a flow to diagram, as will become evident in 
the preceding paragraphs. 

RST is the interval between the moment RPT is completed fo the moment 
the procurement document is accepted by the procurement activity. “Acceptance” occurs 
only when FISC Customer Service, FISC Technical, and the FISC buyer are satisfied that 
the document is administratively complete and provides sufficient information to make the 
buy. Delays caused by requests for additional data are included in RST (see Appendix F 
for top reasons why requisitions are returned to the ship). RST is almost nonexistent in 
credit card purchases as these purchases are never delivered to the FISC; after the 
requisition number is assigned, the document is accepted by the buyer (i.e., credit card 


holder, likely the same SK). /Ships reported harid-delivering or mailing 3 to 15 
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nonstandard procurement documents to the procurement activity/FISC a month.] The 
document is first submitted to/received at FISC Customer Service where it is 
administratively screened. The document is then forwarded to FISC Technical where the 
requirement is again technically screened for NSN substitutes, HAZMAT compliance, and 
authorization for shipboard use. Any data inconsistencies or omissions are resolved with 
the ship. After technical screening, it is forwarded to the FISC buyer for contract award. 
[Depending on the urgency and mode of delivery to the FISC, RST was completed in 45 
minutes to ten days. RST for credit card buys took less than one minute. ] 

PALT is the interval between the moment the procurement document is 
accepted by the buyer to the moment the contract is awarded; in other words, it is the 
measure of the time it takes the buyer to make a buy. PALT standards vary among 
different procurement activities. PALT for credit card purchases is assigned to the SK 
who prepares the DD Form 1155 and contracts with a local vendor for the repair part or 
consumable material requirement. /Depending on the urgency, PALT at the FISC took 


one hour to 15 days. PALT for credit card buys made by the ship took one to 1.5 hours. ] 








Process Hand-delivered 





FISC meme aaeemat 
RST 5 min - 1.5 hrs 3 - 10 days 
PALT hr - 15 days 1 hr - 15 days 


Total RST/PALT at FISC 75 hrs-15 days | 3-25 days 







Credit card (onboard a ship) 


RST <1 min 
N/A 


PALT 1 - 1.5 hrs 
Total RST/PALT on ship 


Table 3.2 Manual RST and PALT (Ships to FISC) 
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Duration 


1.08 hrs - 27.35 hrs 
<1 min - 10 days 
1_hr - 15 days 


2 hrs - 26 days 


Process Segment 







Total Cycle Time 


Table 3.3. Manual Cycle Time (Ship to FISC) 


2 Manual Process Flow Through Submarine to SLSC to FISC and 
Buyer 

The following manual procurement process flow discussions and depictions are 
derived from the author’s personal interviews with the Supply Officer and Leading SK 
assigned to USS KEY WEST (SSN 722), homeported in Pearl Harbor, the officers in 
charge of the Submarine Logistics Support Center, Pearl Harbor Detachment (SLSC-PH), 
the SUBPAC Force Supply Officer and Force Storekeeper, and FISC-PH personnel. 

Submarines submit most, if not all, of their nonstandard requisitions while in port. 
All are hand-delivered to the SLSC-PH (or equivalent in other ports). To date, SUBPAC 
submarines do not maintain their own credit cards. Submarines, in the interest of stealth, 
keep electronic transmissions to a minimum while underway. /Submarines reported 
imitiating 15 nonstandard procurements a month, or 0.5 per day. Micro-purchases 
accounted for 99 percent and, of these, 95 percent were recurring MVO requirements. 
RPT was equal to that of ship MVO RPT, about one hour to one day (see Table 3.1, MVO 
column). Depending on the urgency of the requirement, and method or type of 
procurement, RST/PALT took 2 hours to 10 days (see Table 3.4). Total Cycle Time 


ranged from 2.17 hours to 11 days (see Table 3.5).] 


38 


a. Manual Requisition Preparation Time (RPT) 

RPT is the same as that onboard a surface ship. Figure 3.1 is equally 
applicable to submarines. However, 99 percent of nonstandard requirements ordered by a 
submarine are MVO requirements and are usually of a recurring nature and, thus, require 
less technical screening. /Jnitial research for MVO requirements ranged from five 
minutes if of a recurring nature to one hour if a manufacturer or vendor was contacted. 
Ordering MVO requirements took two to five minutes. Document preparation and 
delivery to the SK took from 10 to 30 minutes. Administrative screening took one to two 
minutes. Technical screening took 15 to 60 minutes, depending on whether the 
manufacturer or vendor was again contacted, whether the material was hazardous or 
restricted, etc. Approvals took anywhere from 30 minutes to a day, depending on the 
nature of the requirement (e.g. HAZMAT) and the availability of the Department Head, 
Commanding Officer, etc. It took two to four minutes to assign a requisition number. ] 

b. Manual Requisition Submission Time (RST) and Manual 

Procurement Administrative Lead Time (PALT) 

Interposed between the submarines stationed in Pearl Harbor and FISC-PH 
is the SLSC-PH, which is located in the same building as the FISC. All SLSC-PH 
branches (i.e., Customer Service, Technical Section, and the credit card buyers) are 
located in the same open workspace. Manual RST and PALT for submarines are 
diagrammed in Figure 3.3. 

The requisition is first submitted to Customer Service, where the document 
is logged in and administratively screened. It is then forwarded to the Technical Section 


where the requirement is again technically screened for NSN substitutes, HAZMAT 
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compliance, and authorized shipboard use. Any inconsistencies or omissions are resolved 
with the submarine, and the resultant delays are included in RST. After technical 
screening, the requirement is walked to either the FISC buyer (because a second technical 
screening is conducted by the SLSC-PH, the document bypasses FISC Technical) or, if'a 
credit card purchase, to one of three SLSC-PH credit card holders. /RST was completed 
in 45 minutes to 1.5 hours. There is no significant difference between RST involving 
credit card buyers or FISC buyers. ] 

PALT for credit card purchases is assigned to the SLSC-PH buyer who 
prepares the DD 1155 and contracts with the local vendor for the consumable material 
requirement. PALT for other types of procurements are assigned to the FISC buyer. The 
close proximity of SLSC-PH to the FISC buyer ensures that critical requirements are 
procured rapidly. Low-priority requirements are not so forcefully expedited by SLSC-PH, 
but are expedited nonetheless. Copies of contracting forms are maintained by the SLSC- 
PH in addition to those mailed to the submarine. {Depending on the urgency, PALT for 


credit card buys took 20 minutes to 1.5 hours. PALT at the FISC took 1 hour to 10 


days. ] 











Process Segment Duration 


| RST (hand-delivered) 45 min - 1.5 hrs 
PALT (credit card buy) 20 min - 1.5 hrs 
PALT (FISC) 1 hr - 10 days 


Total RST/PALT 2 hrs - 10 days 





Table 3.4 Manual RST and PALT (Submarine to SLSC to FISC) 
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Duration 


1.08 hrs - 26.65 hrs 
45 min - 1.5 hrs 
20 min - 10 days 


2.17 hrs - 11 days 


Process Segment 







Total Cycle Time 


Table 3.5 Cycle Time (Submarine to SLSC to FISC) 


Be ANSRS Process Flow Through Surface Ship to FISC and Buyer 

The following ANSRS procurement process flow discussions and depictions are 
derived from questionnaire responses and telephone interviews with supply personnel from 
activities installed with the ANSRS prototype, including ships and FISCs. Telephone 
interviews were also conducted with ANSRS Program personnel at NAVSUP and 
NAVICP-M. [Ships reported initiating 15 to 90 nonstandard procurements a month, or 
0.5 to three a day. Approximately 75 percent were credit card purchases for those 
commands using a credit card. Depending on the type and urgency of the requirement, 
RPT was completed in 52 minutes to more than one day (see lable 3.6). Again, 
depending on the type and urgency of the requirement, RST/PALT took 30 minutes to 2.5 
hours (see Table 3.7). Total Cycle Time ranged from 1.37 hours to more than a day (see 
Table 3.8).] 

Figure 3.4 is similar to the manual procurement process flow diagrammed in 
Figure 3.1 as ANSRS does not actually e/iminate any steps, but instead automates them. 
Figure 3.4 assumes an interface between SNAP and ANSRS on a LAN-capable ship. The 


dotted lines indicate those steps automated by ANSRS. Likewise, Figure 3.5 is similar to 
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Figure 3.2 and assumes neither EDI nor interface problems between the ship and FISC and 
within the FISC. 

a. ANSRS Requisition Preparation Time (RPT) 

ANSRS RPT is diagrammed in Figure 3.4. RPT begins when the end-user 
identifies a requirement through an initial research that may include technical manuals, 
drawings, microfiche/film/CD-ROM libraries, discussions with manufacturers, and 
personal records. Either a repair part or an MVO requirement will be eventually ordered. 
ANSRS 1s useful as a research tool in this step for identifying MVO cage/part numbers for 
items such as paint. If the requirement is for a repair part, the end-user will open a 
maintenance job in SNAP and search the equipment’s APL for an NSN match. If no 
match is found, the end-user will access the ANSRS program and order the requirement 
by cage and part number. MVO requirements can also be ordered by accessing the 
ANSRS program as no maintenance job 1s opened or needed. ANSRS will automatically 
check for NSN substitutes on those cage/part number relationships resident within the 
NSDB; the FEDLOG can also be accessed through ANSRS. The end-user next selects a 
procurement document format and fills in the required information. If the cage/part 
number relationship is resident within the NSDB, the information will already be provided 
on the document. The document is then ready for an online technical screening by an SK. 
[Initial research for repair parts or MVO requirements ranged from two minutes to one 
hour depending on whether the cage/part number relationship was resident in ANSRS 
and/or a manufacturer or vendor was contacted. Ordering a repair part took 20 to 45 
minutes, most of which was spent opening the requisite job and conducting an APL 


search, and again depending on whether the cage/part number relationship was resident 
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in ANSRS. Ordering MVO requirements took two to five minutes. Document preparation 
took froni five to ten minutes. ] 

The SK accesses the document and reviews it for completeness and errors. 
If the requirement is for a repair part or consumable material the SK will access the 
FEDLOG, the SHML, and/or other online databases to check for NSN substitutes and 
determine if the material 1s hazardous or otherwise restricted. Requirements for services 
will be checked against regulations delineating authorized service requirements, some or 
all of which may be online. {Administrative screening took one to two minutes. Techical 
screening took ten minutes to one hour depending on whether a manufacturer or vendor 
was contacted, whether the material was hazardous or restricted, and whether FEDLOG 
and other databases were online ANSRS. ] 

After the screening 1s completed, the document is ready for a series of 
online approvals by all necessary personnel including the Hazardous Material Officer (for 
HAZMAT), the Department Head, the Commanding Officer (for restricted material and/or 
HAZMAT), and the Supply Officer. If the requirement is urgent, the end-user may have 
to “urge” these officers to access their computers, a potential bottleneck, especially with 
Commanding Officers who may be occupied with other tasks. After all requisite approvals 
are obtained, the SK assigns it a requisition number. At this point, SNAP maintenance 
and financial modules will be automatically updated. The procurement document and any 
ancillary documents, such as Material Safety Data Sheet (MSDS), is then ready for 
transmission, or batched and awaiting transmission, via EDI to the procuring activity, 
usually the local FISC. RPT is identical for credit card purchases. [Approvals took 


anywhere from 30 minutes to a day, depending on the nature of the requirement (e.g. 
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HAZMAT) and the availability of the Department Head, Commanding Officer, etc. It 


took two to four minutes to assign a requisition number. | 






Task 





Duration 

(MVO) 

2 - 5 min 

5 - 10 min 
] 


Duration 
(repair parts) 











Assign requisition number 


Total RPT 1.17 hrs - 27.02 hrs 52 min - 26.35 hrs 






Table 3.6 ANSRS RPT for Ships 


b. ANSRS Requisition Submission Time (RST) and ANSRS 
Procurement Administrative Lead Time (PALT) 

ANSRS RST and ANSRS PALT for procurement documents that are 
transmitted to the procurement activity/FISC for award are diagrammed in Figure 3.5. 
RST and PALT for credit card buys is too simple a flow to diagram, as will become 
evident in the preceding paragraphs. 

RST is the interval between the moment RPT is completed to the moment 
the procurement document is accepted by the procurement activity. Delays caused by 
requests for additional data are included in RST. With ANSRS, however, those requests 
can be made via EDI; so too can the responses from the ship. RST is nonexistent in credit 
card purchases because these requirements are never transmitted to the FISC. After the 


requisition number is assigned, the document is automatically accepted by the buyer (i.e., 
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credit card holder, likely the same SK). /Ships reported transmitting six to eight 
nonstandard procurements to the procuring activity/FISC a month.] The procurement 
document is transmitted to/received at the FISC via EDI where it is administratively 
screened by Customer Service. Next, FISC Technical conducts another technical 
screening for NSN substitutes, HAZMAT compliance, and other restrictions to shipboard 
use. Any discrepancies are resolved with the ship via EDI (there should be no data 
omissions). After technical screening, the document is ready for the FISC buyer to 
contract award. /Sice all FISCs reported difficulties with receiving transmissions from 
a ship andor internal incompatibility problems, RST completion is estimated at 45 
minutes to 1.5 hours. RST for credit card buys was nonexistent. ] 

PALT is the interval between the moment the procurement document is 
accepted by the buyer to the moment the contract is awarded (or, the amount of time it 
takes the buyer to make the buy). PALT standards vary among different procurement 
activities. PALT for credit card purchases is assigned to the SK who contracts with a 
local vendor for the repair part or consumable material requirement. /Depending on the 
urgency, PALT at the FISC took 30 minutes to 15 days. PALT for credit card buys made 


by the ship took 30 minutes to one hour.] 
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Process Segment Duration 


FISC alana 
RST 
PALT 
Total RST/PALT at FISC 


Credit card (onboard a ship) a a 
RST 
PALT 30 min - | hr 


Total RST/PALT on ship 30 min - 1 hr 























Table 3.7. ANSRS RST and PALT (Ship to FISC) 








Process Segment Duration 


RP 52 min - 27.02 hrs 
S O- 1.5 hrs 
PALT 30 min - 1 hr 


Total Cycle Time 1.37 - 29.52 hrs 






Ps) 
4/4 















Table 3.8 ANSRS Cycle Time (Ship to FISC) 


D. CHAPTER SUMMARY 

This chapter began with brief discussions on ANSRS implementation background, 
schedule, and responsibilities. Next, the prototype Afloat Customer Module was 
presented. The core of this chapter discussed, diagrammed, and quantified the manual 
procurement process on both surface ships and submarines and the ANSRS procurement 
processes on ships (ANSRS has not been installed onboard any submarine to date). Task 


completion times were given as a minimum to maximum value range. 
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Manual RPT for both surface ships and submarines are comparable. However, 
repair parts take approximately 37 percent longer to order than MVO requirements, 
principally because of time expended opening a maintenance job, and submarines rarely 
order a nonstandard repair part. ANSRS creates some small time savings for ships but 
does not significantly reduce the range; similar results are likely for submarines. 

RST and PALT differences between ships and submarines can be attributed to 
whether or not the requirement has to be delivered to an external procurement activity 
and, if so, the delivery method used. For ship requirements hand-delivered to the FISC, 
RST/PALT ranged from 1.75 hrs to 15 days; mailed documents took from three to 25 
days. Submarines hand-deliver all their procurement documents to an intermediate 
support activity such as SLSC-PH. For submarines, RST/PALT for FISC buys ranged 
from 1.75 hrs to 10 days. The shorter maximum is attributed to the expediting efforts of 
the SLSC-PH, which is located in the FISC building. ANSRS creates significant 
RST/PALT time savings for ships when near-instantaneous delivery time and elimination 
of additional technical screening at the FISC is factored in. Maximum values are reduced 
from 25 days to as little as 2.5 hours. When credit cards are used, RST/PALT maximums 
for ships are about half of that for submarines, 1.5 hours compared to 3 hours. Submarines 
(in SUBPAC) do not have their own credit cards as yet and must hand-deliver the 
requirement to the intermediate support activity. ANSRS reduces RST/PALT for credit 
card time by 30 minutes on both sides of the range, principally because of paperwork 
reductions. ANSRS creates reductions in Cycle Time maximums for ships from 26 days 
under the manual process to under 30 hours. ANSRS would likely produce a similar 


maximum for submarines. 
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Figure 3.1 


Manual Procurement Process Flow: Requisition Preparation Time (RPT) for Surface 


Ships and Submarines 
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Manual Procurement Process Flow: Requisition Submission Time (RST) and Procurement Administrative Lead 
Time (PALT) for Surface Ships 
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IV. DATA COLLECTION AND ANALYSES 

This chapter focuses on the questionnaire used in this study (Appendix E). It was 
selected as the primary research tool to measure the effectiveness of ANSRS prototype 
implementation. Background is presented, responses are discussed and tabulated (where 
applicable), and the results are analyzed. Additionally, an example of an unsuccessful 
prototype installation is discussed, diagrammed, and analyzed. Finally, a brief analysis on 
measures of effectiveness and cost is presented. 
A, QUESTIONNAIRE BACKGROUND 

In order to ascertain the efficacy of ANSRS to the Navy customer, a questionnaire 
was developed and submitted to all Pacific Fleet commands installed with any one of the 
three ANSRS prototype modules. On 5 November, 1997, the questionnaire was directly 
emailed to 27 points of contact assigned to 21 commands. These commands consisted of 
eight SURFPAC ships, one AIRPAC ship, seven FISC/FISC satellites, one Naval Air 
Station, two Ship Repair Facilities (SRF) and two Fleet Activities (FLEACT) in 
California, Washington (State), Hawai, and Japan. Follow-up telephone calls revealed 
some instances where software incompatibility rendered the questionnaire unreadable, 
requiring 13 questionnaires to be resent via fax and three to be subsequently conducted 
over the telephone (by request of the respondent). Because some ships were underway 
and could not be reached by telephone until late in the month, the last fax was transmitted 
on 20 November. All but three points of contact were confirmed to have received the 
questionnaire (no telephone number was provided for these three, and email follow-ups 
were not answered). The accompanying cover letter requested that all ANSRS users 


within a command be given the opportunity to respond. Discussions with a cross-section 
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of the commands suggested that approximately 107 personnel were potential respondents. 
Eventually, 42 responses were received (39%), consisting of 8 Supply Corps Officers, 18 
Storekeepers, 4 RPPOs, and 12 civilians. Follow-up questions were conducted with 16 
points of contact. 

B. QUESTIONNAIRE RESPONSES AND ANALYSES 

This section is divided into the broad categories of the questionnaire. Some 
questions required either short or essay responses, while others were yes/no or Likert- 
Type Scale in design. First, the rationale behind each category is discussed. Next, all 
questionnaire questions are repeated verbatim (in bold type), responses tabulated where 
applicable, and remarks provided for clarification. An analyses is presented at the end of 
each category. 

1. Manual Open Purchase Process (Pre-ANSRS, Pre-Credit Card) 

This category of questions was designed to obtain information on the manual 
nonstandard procurement processes flow from the end-users perspective, problems and 
bottlenecks encountered, and LRT. This information was incorporated into those sections 
in Chapters II and III that discuss and/or quantify the manual procurement process. It was 
also used, in part, to diagram Figure 3.1. 

a. Briefly describe the process flow (from end-user to the 
contracting activity’s customer service desk), approximate time 
involved in each step, the personnel involved in each step, and 


any paperwork or document requirements. 


Remarks: See Figure 3.1 for a composite manual nonstandard 
procurement process flow. 
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What problems did (do) you encounter with the manual open 
purchase process? What and where in the process were (are) 
the bottlenecks? 


Responses: Obtaining signatures: 13 (31%) 
Lack of communication between 
ship and FISC 135G1%) 
Incomplete information from 
end-user: 12 (29%) 


Remarks: Some respondents provided more than one answer. 


Approximately how long did (does) it take to receive your 
material this way? 


Responses: Range: 3 weeks to 1 month for CONUS 
activities 
30 to 60 days for OCONUS activities 


Remarks: This question would have been more germane to this 
study had it asked “Approximately how long does it take for your 
requirement to be awarded at the procurement activity?” 


Analysis: Afloat and shore end-users had little difficulty explaining the process 


flow and the bottlenecks encountered. They could not, however, accurately quantify the 


temporal aspects of the process. This was not unexpected; despite the evident need to 


automate processes in this time of downsizing, measuring those processes is a difficult 


task, at best. This deficiency has lead to more than one automated system to be developed 


and implemented at great expense within the fleet, only to be abandoned or underutilized 


by those it was meant to help because it could not be shown, quantitatively, how it would 


improve the process. Of the three bottlenecks mentioned, only the former, obtaining 


signatures, will likely be exacerbated by automation because a busy officer is more likely 


to sign a piece of paper presented during a small break in the action than drop everything 


to log on the terminal. Expediency will, in all probability, lead to password violations. 
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2 IMPAC Credit Card 


ANSRS is the only known program (to the author) that captures credit card 


demand and is expected to be deployed throughout the fleet. This category was designed 


to provide an idea on how prevalent credit card use is in the fleet. 


a. 


Do you currently use the IMPAC credit card? 


Responses: Yes: 29 (69%) 
No: 13 31%) 


If so, since when? 
Responses: Range: 2 - 11 months. 


Describe the workload that was reduced or eliminated. By 
what percentage? 


Responses: Simplifies procurement process: ES 
(S2% of credit card users) 
Easier tracking/monitoring: 7 
(24% of credit card users) 
Receive material faster: 7 
(72% of credit card users) 
Range: 90 - 100% 


Remarks: Some respondents provided more than one answer. 
RPPOs reported 100% workload reductions. 


Describe the workload that was increased or created. By what 
percentage? 


Responses: |More open purchase demands: 12 
(41% of credit card users) 
Increased validation of requirements: 12 
(41% of credit card users) 
Bill/payment auditing: 19 
(66% of credit card users) 
Range: 30 -75% 
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é. Do you feel that the credit card makes your job easier? 
Harder? Why? 


Responses: Easier: 24 
(83% of credit card users) 
Harder: 5 
(17% of credit card users) 
Remarks: Responses to the third part of this question are 
incorporated into questions c and d. All shipboard personnel 
responded easier. 

Analysis: All but one ship used the credit card, which attests to its popularity with 
afloat commands. However, several respondents reported an increased reliance on the 
credit card for ordering repair parts and a corresponding increase in totai open purchase 
requests. It appears that many maintenance personnel are focusing their efforts on 
identifying local sources of procurement instead of relying on the supply system. This 
could result in negative configuration control ramifications as non-approved parts make 
their way into the “this is what we’ve always used” category while the equipment keeps 
failing. It could also degrade readiness for deployed ships when the equipment breaks and 
there is no local supplier. Total Asset Visibility (TAV) objectives are also compromised. 
However, it also points out that the “system” 1s not satisfying all of its customers. 

3. ANSRS Training 

This category was designed to obtain customers’ perceptions on the quality of the 
training provided. Its intent was to determine whether training was successful in providing 


the necessary skills to operate ANSRS and alleviating any initial trepidation towards its 


use. 
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When did you first hear about ANSRS? 


Responses: __ Prior to install: 35 (83%) 
During install: 7 (17%) 


Remarks: One command reported a 37 month notification; most 
reported 8 - 9 months 


What types of training did you receive? Duration? 


Responses: None: 0 
Self-training: 0 
1 on 1: 20 (48%) 1 hr. 
Group: 16 (38%) 1 to 4 hrs. 
Lecture: 14 (33%) 1 to 4 hrs. 
Hands-on: 11 (26%) 2 to 4 hrs. 
Other: 0 


Remarks: Some respondents reported receiving more than one type 
of training. 


Would you describe the training as good, thorough, and 
worthwhile? If not, what would have helped? 


Responses: Yes: 25 (60%) 
No: 17 (40%) 


Remarks: Yes includes “adequate” or “satisfactory” responses. 
Some respondents felt that training should include actual 
transmissions and/or responses from the FISCs. Two (from 
different commands) felt that the instructors did not know their 
subject matter very well. One reported that people walked out 
during the training session. 


At what point did you understand what ANSRS was intended 
to do? 


Responses: _ Pre-training: 14 (33%) 
During training: 16 (38%) 
After working with it: 2 (5%) 
Still somewhat unclear: 10 (24%) 
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e. At what point did you understand how to use ANSRS? 


Responses: __ During training: 19 (45%) 
After working with it: 13 (31%) 
Still somewhat unclear: 10 (24%) 
if How difficult is it for you to adequately train someone within 


your organization on ANSRS? 


Responses: —_Haven’t had to yet: 16 (38%) 
Not difficult/easy: 15 (36%) 
Moderately difficult: 11 (26%) 
Very difficult/hard: 0 
Impossible: 0 
g. How would you improve ANSRS training within your 
command? 
Responses: — Hands-on training: 15 
(58% of those who have trained) 
Devote more time: 3 
(12% of those who have trained) 
No response: 8 


(31% of those who have trained) 


h. Do you know where to get assistance within your organization 
if needed? 


Responses: Yes: 37 (88%) 
No: 5(12%) 


1. Do you know where to get assistance outside your organization 
if needed? 


Responses: Yes: 36 (86%) 
No: 6(14%) 


j. Do you know how or where to send feedback or suggestions? 


Responses: Yes: 31 (74%) 
No: 11 (26%) 


Analysis: All respondents reported receiving at least one type of training. 


However, 40 percent did not find the training worthwhile, and ten percent are still unclear 
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on how to use ANSRS. Additionally, 14 percent of the respondents did not know where 
or from whom to get outside assistance, and 26 percent did not know how or where to 
send feedback and suggestions. Additionally, 42 percent of personnel who attempted to 
train someone within their command found the task moderately difficult. These indicators 
point to the essentiality of tailoring training to the customers’ needs. 

4. ANSRS Usage 

This category was primarily designed to provide the information to be used in 
comparison with the manual procurement process; this information was incorporated into 
Chapter III and was used, in part, to diagram Figures 3.4 and 3.5. It was also intended to 
discover if a causal relationship could be determined between usage, training, and 
installation. 


a. How often do you use ANSRS? 


Responses: Daily: 20 (48%) 
Weekly: 11 (26%) 
A few times per month: 0 
Rarely: 0 
Never: 11 (26%) 


b. What do you use ANSRS for? 


Responses: | NSN screening: Is 
(48% of ANSRS users) 
HAZMAT screening: 4 
(13% of ANSRS users) 
Mandatory source screening: 15 
(48% of ANSRS users) 
Credit card procurements: 2 
(39% of ANSRS users) 
Other small purchases: 1] 
(35% of ANSRS users) 
Large procurements: 17 
(55% of ANSRS users) 
Other: 0 
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Remarks: Some respondents reported more than one use. 


Who uses ANSRS in your organization? 


Responses: | Commanding Officer: 0 
Executive Officer: 0 
Supply Officer: 12 
HAZMAT Officer: 0 
Storekeepers: DS, 
RPPOs: 44 
Others: 19 


Briefly describe the process flow (from end-user to the 
contracting activity’s customer service desk), approximate time 
involved in each step, the personnel involved in each step, and 
any paperwork or document requirements. 


Remarks: See Figures 3.4 and 3.5 for composite ANSRS 
procurement process flows. 


What and where in the process are the bottlenecks? 


Responses: No internal interface/cannot 


update files: 29 (69%) 
Obtaining signatures: 13 (31%) 
No external interface/connection: 2 (5%) 


Remarks: Some respondents provided more than one answer. 


Approximately how long does it take to receive your material 
this way? 


Responses: No significant variation from question 15 responses 
(p. 53). 


Remarks: Same as question 15 remarks (p. 53). 


Does ANSRS decrease your workload (e.g. saves time, saves 
paperwork?) 


Responses: Yes: 21 (68% of ANSRS users) 
No:  10(32% of ANSRS users) 
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If yes, describe how and rank in order of importance to you. 


Responses: _ Trips to/time spent at the FISC: 13 
(62% of yes respondents) 
No response: 8 


(38% of yes respondents) 
Does ANSRS increase your workload in any area? 


Responses: Yes: 27(87% of ANSRS users) 
No: 4(13% of ANSRS users) 


If yes, describe how. 


Responses: Double entry of data: oD 
(81% of yes respondents) 
Added step in credit card process: 8 
(30% of yes respondents) 
No response: 9 
(33% of yes respondents) 


Remarks: Some respondents provided more than one answer. 


What should ANSRS do for you that it cannot now do? 


Responses: __ Interface with FEDLOG: 13 31%) 
ANSRS should match manual forms: 8 (19%) 
Import scanned files: 4 (10%) 
Make job easter: 4 (10%) 
Upload to APADE: 2 (5%) 
No response: 11 (26%) 


Does your command receive a Non-Standard Data Base 
(NSDB) update on a regular basis? 


Responses: Yes: 24 (57%) 
No: 18 (43%) 


Remarks: No includes “don’t know” responses. 
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m. If yes, how often? 
Responses: Once: 8 
(33% of yes respondents) 
No response: 16 
(67% of yes respondents) 
n. Does ANSRS interface with FEDLOG? 


Responses: Yes: 22 (52%) 
No: 20 (48%) 


O. Is ANSRS installed on a LAN within your organization? 
Responses: Yes: 2] (50%) 
No: 21 (50%) 
p. Do you like ANSRS? 


Responses: Yes: 23 (55%) 
No: 7(17%) 


Remarks: 12 (30%) did not understand this question. It should be 
rewritten to ask “Do you like the concept behind ANSRS?” 


Analysis: The ANSRS prototype has not been very successful. More than a 
quarter of respondents don’t even use it and another ten percent are using it less 
frequently than before. Those that do use ANSRS are not receiving the full benefits that 
ANSRS was designed to provide. Less than half of those who still use ANSRS do not use 
it for technical screening. Although 68 percent of those using ANSRS reported that it 
lessened their workload, the major reason cited was that it saved a trip to the FISC. 
Conversely, 87 percent of those who use ANSRS reported that it increased their 
workload. By far, the most common problem encountered was double entry of data 
caused by the lack of interface with other systems, principally SNAP. It appears that, 
although training was not fully successful, indoctrination was; the majority of respondents 


were eager to have a system like ANSRS, but “one that works.” 
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=" Miscellaneous 

This category was designed to complement the previous questions and to provide 
specific information on all nonstandard procurements initiated by each command and the 
amount of additional equipage required to implement and use ANSRS. This information 
was also incorporated into Chapter IIL. 


a. On average, how many open purchase requisitions do you 
submit per month for credit card purchases? 


Responses: Less than 6: 0 
6-10: 0 
11-15: 0 
16-20: 4 
(14% of credit card users) 
21-25: 1 
(41% of credit card users) 
More than 25: 13 
(45% of credit card users. Range: 33 to 63) 
b. Non-credit card small purchases? 
Responses: Less than 3: 31 (74%) 
3-5: 3 (7%) 
6-10: 5 (12%) 
11-15: 0 
16-20: 3 (7%) 
More than 20: 0 
@ Large purchases? 
Responses: 1 0 
Z 2 (5%) 
Bs 1 (2%) 
4: 1 (2%) 
More than 4: 6 (14%) 


(Range: 6 to 8) 


Remarks: 30 (71%) respondents reported zero. 
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Approximately what percentage of open purchases are for 
repair parts (vice consumables, equipage, services, etc.)? 


Responses: Credit card: 18 (62%) 
(of credit card users. Range: 25% to 95%) 
Non-credit card small: 11 (26%) 
(Range: 20% to 25%) 
Large: 7 (17%) 


(Range: 5% to 25%) 


Approximately what percentage of open purchases are 
procured using ANSRS? 


Responses: Credit card: 14 (48%) 
(of credit card users. Range: 25% to 90%) 
Non-credit card small: 8 (19%) 
(Range: 25% to 100%) 
Large: 17 (40%) 


(Range: 10% to 100%) 


What kinds and how much extra equipage (e.g. terminals) was 
needed to implement ANSRS within your organization? 


Responses: One terminal and monitor: 4 (10%) 
None or no response: 38 (90%) 


Analysis: One afloat command reported that 95 percent of its credit card 


purchases were for repair parts. This appears grossly excessive, but the ship could not be 


reached for clarification. Generally, the usage rates reported were credible and ordinary. 


Additional Comments 


This section was used to elicit any comments that respondents felt were important 


but not addressed above. However, most comments applied to the previous categories 


and were incorporated therein. 


Comments: 
Using ANSRS less frequently than before: 4 (10%) 
ANSRS should only be used at FISC: 3 (7%) 
ANSRS still being installed: 2 (5%) 
No response to feedback: 1 (2%) 


Go 


Cc ANSRS IMPLEMENTATION AT FISC PEARL HARBOR 

When ANSRS is unsuccessfully implemented, human energy is expended to “work 
around” the problems encountered, resulting in other process flow disruptions and causing 
resistance to change. Figure 4.1 illustrated how the unsuccessful implementation of 
ANSRS at FISC-PH creates and inefficient process flow, and in one instance actually 
causes additional workload for the ship. 

Procurement document data in ANSRS format is either hand-delivered on a disk 
or transmitted via SALTS to Customer Service. If received via SALTS, the data is 
downloaded to a disk because SALTS does not interface with ANSRS. The disk is 
walked to Technical for technical screening. The procurement data can be sent via email, 
but this mode of transmission bypasses Customer Service and instead goes directly to a 
terminal in Technical. The data is imported into ANSRS for technical screening. If there 
are no discrepancies, a hard copy of the DD 1155 is printed and walked to the buyer. 
However, if either Technical or the buyer discover any discrepancies, the ship is contacted 
and a brand new procurement document, not the old one with updated/corrected 
information, must be generated by the ship and transmitted. Corrections cannot be made 
by FISC personnel. 

D. MEASUREMENTS OF EFFECTIVENESS AND COST 

One may conclude that, generally, automating any manual process will produce 
efficiencies in labor, paper, time, and other resources. However, unless one can measure 
segments of the process and apply costs, one cannot quantify those efficiencies with any 
degree of precision. Since the objective of this study is to determine the feasibility of 


implementing ANSRS within SUBPAC, the ability to quantify data and conclusions is 
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imperative. Research indicates, however, that few measures of effectiveness and costs 
related to the nonstandard process exist; those that do are not standardized. 

The analysis presented at the end of paragraph B1 stated that those personnel who 
responded to the questionnaire had a difficult time providing temporal measures. This 
task was equally difficult for NAVICP, NAVSUP, contracting, and contractor personnel. 
The measures are just not there. To compensate, the author improvised: “Cycle Time” 
defined as a truncated segment of its usual meaning—LRT—but with an additional 
segment to measure the time it takes to develop and process a requirement before 
assigning a requisition number to it—RPT. The author attended a symposium on LRT in 
August 1997 and discovered that although RST was defined, there were many disparate 
opinions on how to measure it, and no rational way to cost it. PALT is a generally 
understood term, but it too does not conform to any hard and fast standard, and any cost 
measurements associated with it could not be provided to the author. 

E. CHAPTER SUMMARY 

ANSRS prototype implementation has not wrought the efficiencies that were 
intended. Several questionnaire responses and the unsuccessful implementation of 
ANSRS at FISC Pearl Harbor support this argument. Training was only partially 
effective. Connectivity problems, both internal and external, are significant impediments 
to ANSRS acceptance and usage. However, the efficiencies and resultant workload 
reductions that ANSRS could provide are attractive to and desired by fleet customers. 
The paucity of standardized and/or useful measures of effectiveness and cost creates a 
significant obstacle to current ANSRS implementation objectives and future ANSRS 


improvement initiatives. Preliminary benchmarks are offered with the survey results. For 
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maximum ranges, problems should be identified and resolved so to reduce variation in the 


process. 
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V. CONCLUSIONS AND RECOMMENDATIONS 

The data collected for this study, while not always as precise as desired, is 
nonetheless sufficient to draw conclusions pertinent to the objective of this study and 
identify areas that warrant further research. This final chapter begins with conclusions and 
recommendations and ends with peripheral issues that appear to be valid candidates for 
later research. 

A. CONCLUSIONS AND RECOMMENDATIONS 

1. It would be beneficial to implement ANSRS within SUBPAC. 

ANSRS should be implemented within SUBPAC, on submarines and at SLSC-PH 
(to include the other SUBPAC shore/tender activities that provide the same types of 
services as SLSC-PH). The data indicates that ANSRS implementation can create 
significant time efficiencies for ships. A comparison of Tables 3.3 and 3.8 shows that total 
Cycle Time can be reduced from a high maximum of 26 days to a low maximum of Just 
over one day. This significant reduction is predicated on the elimination of connectivity 
glitches, a broadly stocked NSDB, and a minimum of document errors generated by the 
ship. Indeed, if left unresolved these problems will create the same or worse results as the 
prototype has produced so far. The development of the Windows NT version is a step in 
the nght direction. 

The entire case for implementing ANSRS within SUBPAC is not based solely on 
efficiencies from which ships might benefit. As stated in the opening paragraph of Chapter 
III, the submarine community is logistically different than the surface and air communities. 
SUBPAC’s successful efforts to reduce the workload of the afloat Supply Department 


(the stated rationale behind SLSC-PH, e¢ a/.) allows submarine supply personnel to 
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concentrate on configuration management and achieve a greater than 93 percent 
configuration accuracy rate. SLSC-PH also provides a dedicated cadre of personnel to 
expedite all submarine requirements and act as experts at “working the system”. Because 
of these advantages, submarines can better rely on the supply system and rarely order a 
nonstandard repair part. These advantages may erode, however, as the push towards 
inventory reductions and reliance on COTS and NDI—CANDI—equipment, which will 
not likely be supported by the supply system, gains momentum. The secondary support, 
then, for implementing ANSRS on submarines comes from the ability of ANSRS to 
provide NAVICP with equipment support histories and demand data, to be used by 
NAVICP to conduct deep technical screening, maintain the integrity of submarine Weapon 
Systems Files, and avert repair part shortages. There is no evidence to suggest that 
ANSRS implementation will cause significant operational/relational changes between 
submarines, shore support activities such as SLSC-PH, and FISCs. 

a. Build a record of success before implementing ANSRS within 

SUBPAC. 

A proven record of success should be achieved within the other Navy 
communities before implementation begins within SUBPAC. Based on informal 
interviews with numerous submarine officers and enlisted, the interconnectivity problems 
between SNAP and ANSRS, and those between customer, procurement activity, and 
NAVICP must be resolved, or any briefing with “ANSRS” and “improved readiness” will 
likely fall on deaf ears, and may instead be seen as a threat to workload reduction 


imperatives. 
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b. Develop tailored training for submarines and fund pierside 

experts. 

Conduct personal interviews with personnel at all levels of SUBPAC to 
determine readiness objectives and methods use to attain them. Paper surveys and 
questionnaires are not as effective as personal interviews. Operational necessities will not 
always conform to preset training schedules; a pierside expert or two at the FISC will be 
able to provide hands-on training to submarines (and other commands) during windows of 
opportunity. They can hold group training at the FISC if there is surge in demand. They 
will also be available to answer questions, take action on feedback, and obtain NSDB 
updates for commands that may have missed getting one because of deployment. In short, 
they will help sustain user proficiency (afloat and ashore), positively impact logistics 
readiness, and cut down on training travel costs. 

C: Devise a method for obtaining signatures off line. 

The bottleneck common to both the manual and ANSRS procurement 
process questionnaire questions was the difficulty of obtaining approval signatures. The 
author can personally attest that SNAP access passwords belonging to Department Heads 
are given to subordinates. The author can also personally attest that when the practice 
was stopped, the backlog of non-approved requirements in SNAP rose dramatically and 
rapidly. The reason for this is because it is often impractical for officers on watch, 
conducting engineering drills, etc. to break away and access a terminal. FEDEX has the 
ability to obtain paperless signatures they can then upload into their computer system. 


NAVMASSO should easily be able to adapt this technology to ANSRS. A hard copy of 
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the requirement will have to be printed out for review by the signatory, but that is 
preferable to doing nothing. 

ize To measure and improve the process, ANSRS performance and costs 

Should be measurable. 

ANSRS performance and costs have to be measurable. It is not sufficient to only 
install a system such as ANSRS on a submarine and let it perform. It is not unreasonable 
to assume that new policies, whether enacted by Congress or the Navy, will force 
logisticians to redefine business practices in the future. When that time comes, any 
decision to scrap and replace ANSRS, improve it, or do nothing can only be intelligently 
made by researching a bank of re/evant and accurate performance and cost data. 

a. Develop performance indicators. 

The performance indicators provided in this study should be used as 
preliminary benchmarks and improved upon. Shipboard personnel should be able to 
download performance measures that indicate how long a requisition has sat in any or all 
measurement segments including ordering time, technical screening time, awaiting 
approval time, awaiting requisition number assignment time, awaiting transmission time, 
PALT, shipping delay, receipt processing time, etc. Computer systems record the date 
and time of every action; if a key must be stroked to accomplish or record any action, then 
the time interval between those strokes can be measured. This will help the users to 
improve the process by highlighting the bottlenecks. Similarly, users should be able to 
quantify the number and types of nonstandard procurements either submitted or awarded, 


error counts, transmissions via email versus SALTS, etc. 
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b. Develop cost measures. 
Associate standardized cost amounts to each performance measurement. 

Measurement of costs may be useful to ships and other end-users interested in determining 
how much of their operating budget is spent on open procurements. However, costs are 
more likely to be of use at the FISC and NAVICP levels, where specialization of labor and 
tasking is more prevalent and thus more susceptible to budgetary influences. One can 
imagine, however, that if FISCs ever become Working Capital Fund (previously: DBOF) 
activities, their customers will be very interested in cost measurements. 
B. PERIPHERAL ISSUES 

i, Credit Card Usage 

Research data implies that credit cards are being used, to an unknown extent, to 
circumvent supply system repair part logistical support for equipment repair. As stated 
earlier, this could have serious readiness implications for both short-term and long-term 
readiness. Yet it may also foretell how future support, especially for CANDI equipment, 
will be conducted. Since ANSRS captures credit card procurement data, it may play a 
pivotal role in the development and implementation of future logistics support procedures. 
Further research may provide some useful insights or conclusions. 

Ze Technical Libraries 

ANSRS allows the user to access technical libraries online. This, in itself, is not 
justification for reducing or eliminating backup manual library resources. Ships sometimes 
lose all power in emergencies, and then is not the time to have no means for researching 


technical information. It may be of benefit to study if and how the push for “paperless 
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environments” and systems automation affects the Navy’s ability to provide hard-copy 


backup resources. 
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APPENDIX A: TECHNICAL SCREENING EXPERT SYSTEM (TSES) CAPABILITIES 


Source: Ref. 13 
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Is Local Area Network (LAN) compatible, requires 10 MB of hard disk space, approximately 450 KB 
of free RAM. and DOS 3.3 or above. 


Is user-friendly, has a User’s Manual, Tutorial. and context-sensitive Help System available with the 
F] function Kev. 


Incorporates a Training Manual utilized at on-site training sessions and provided to the user facility 
for additional training. 


Program Manager distributes newsletter quarterly with information relevant to TSES. 


Program Manager and support personnel update all databases and reference information prior to each 
quarterly distribution. At present, this is done via discs, scanning, etc. 


Transmits data via SALTS. MODEM, DISC, Bulletin Board, INTERNET. 


Distinguishes by Unit Identification Code (UIC) designator (ex. USS) or, if not identified, by the first 
letter of the requisition to determine if the buy is for ship or shore use and, accordingly. follows two 
different logic paths. 


Provides the user the ability to automatically “fill out” 80-card column MILSTRIP data in the Local 
Database and transmit this information electronically to NAVICP-M for input into the nonstandard 
database for inclusion in the next quarterly distribution. 


Interfaces with eight other data information modules, references, subscriptions at the user’s 
discretion. 


Upon input of a NSN, Part Number or Name, automatically searches the NonStandard Database, as 
well as, five (5) other resident and one non-resident database: Local, Plastic Removal In Marine 
Environment (PRIME), Local HazMat Authorized Use List (AUL), Ships Hazardous Material List 
(SHML), Authorized Medical/Dental Allowance List (AMAL/ADAL), and a non-resident database. 
the Hazardous Inventory Control System (HICS) (if installed as activity LAN or PC application). 
Search provides information, such as: the item is hazardous, non-hazardous; authorized, prohibited; 
replacement NSN available; ODS; plastic with a non-plastic alternative; medical/dental; available in 
HAZMIN Center; requires a Material Safety Data Sheet (MSDS), SHML Feedback Report (SFR), 
NAVSUP Form 87, etc. 


Provides reference material via Function Keys, View Data Menu, Database Tools, some of which are: 
FED-STD-313C, Tables I and II (Appendix A), Material Safety Data, Transportation Data and 
Disposal Data for Hazardous Materials Furnished to Government Activities; Federal Supply 
Classification (FSC) Catalog, H2-1, Part 1, Groups and Classes; NAVSUPINST 4200.85C, Enclosure 
3, Shore and Fleet small Purchase and Other Simplified Purchase Procedures; Dual Cognizance 
(COG) Codes; Special Material Identification Codes (SMIC); Type of Storage Codes (TOS); Special 
Material Content Codes (SMCC); Shelf/Life (S/L) Codes; Shelf Life Action Codes (SLAC); Unit of 
Issue (U1) Codes; Hazardous Characteristics Codes (HCC); Hazardous Material Identification Codes 
(HMIC); Unit Identification Codes (UIC); Acquisition Advice Codes (AAC); Ozone Depleting 
Substance (ODS) Chemical Names; NAVSUP/NA VSEA/NAVAIR/MILITARY SEALIFT 
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14. 


16. 
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18. 


19. 


COMMAND/MARINE CORPS Authorized User List of the ODS Reserve. ODS Procurement 
Approvals. etc. 


Automatically produces correspondence and forms, capturing input information, providing the ability 
for the customer to personalize such correspondence/forms (if standardization is not essential), direct 
to a file and/or transmit via SALTS, MODEM, DISC, INTERNET. 


Allows the user to Batch Process (input a disc in ASCII text file) and automatically screen NSN 
requisitions, divide them into those authorized and not authorized, create a historical summary of 
those not authorized. 


Provides a Batch modify module to enable the user to change all entries in one specific field in either 
the Local or Local HazMat AUL Databases. 


. Provides a Suspense Tickler File on-line which dates those items that require an SFR or NAVSUP 


Form 87 due-back within a specified time. 


Provides a summary of all action either input or captured from the databases and system queries in a 
format which can be electronically transmitted or saved to a file. 


Creates a historical summary which is accessed via a Function key and is saved for a period of six 
months. 


Enables user, via Report Generator, to design and personalize reports, capturing specific database 
fields, tailored by activity to print required reporting information. These forms are saved in the report 
generator, making it easy to print the same information weekly, monthly, quarterly. 


Provides letter built into system for electronic transmission, indicating any problems or enhancements 
to system. Personal contact via phone, and customer visits by Programmer, Program Manager at 
NAVSUP and NAVICP-M and other support personnel has provided and continues to provide 
expeditious programming updates. At present, includes desk top manager amenities, such as, 
calculator, appointment calendar, etc. 
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APPENDIX B: STANDARD PROCESSING ENVIRONMENT FOR ELECTRONIC 


Source: 


DOCUMENTS (SPEED) 


Ref. 13 


1. APPLICATION A runs Customer Workstation via Emulator Control Screen and Workstation System 
Screen. 


a. 


a. 


Allows user to show, edit and browse requisitions, utilizing data validation codes, expedite codes 
and release authorization codes. 


b. Sends requisition to Customer-Host via SALTS subsequent to an error validation check. 
2. APPLICATION B runs Customer-Host via Emulator Control Screen and Customer-Host System 
Screen. 
a. Allows user to get requisitions via filename, select report options and view screen display. 
b. Permits user to approve, edit and browse documents. 
c. Transmits, subsequent to validation, approved requisitions to SALTS. 
d. Provides a system action summary page prior to exit to processing screen. 
3. APPLICATION C runs FISC-HOST via Emulator Control Screen and FISC-Host System Screen. 


Host receives requisitions, downloads requisitions from SALTS, processes receipts and posts 
actions to LAN. 


4. APPLICATION D mns FISC-TECH via Emulator Screen and FISC-TECH System Screen. 


da. 


Allows user to get incoming requisitions, download summary screen, review requisitions, select 
single requisition to approve via browse, and edit requisition. 


Displays MCRL-data, tech advisories, opens pipeline and status input window. 
Displays status and tech certification. 
Releases documents for final processing. 


Transmits all completed work to APADE/UADPS/SALTS. 
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APPENDIX C: ANSRS OBJECTIVES 
Source: Ref. 13 
SYSTEM 


The system objectives are analogous to all aspects of the ANSRS program and identify what the whole 
system will do subsequent to meeting all the objectives listed. 


1. To provide a single automated requisition processing/technical screening system that will 
accommodate all new technologies and utilize the best of the existing systems 1n order to facilitate 
centralization and optimization of the technical screening function for nonstandard material 
requisitions. 


2. To perform a basic-level technical review (customer level) of each requirement, generate an electronic 
requisition, download requisition via SALTS and forward to the CTA/FISC. 


3. To automatically screen incoming electronic requisitions through the CTA and generate status in the 
NAVICP Document Status File (DSF). 


4. To build validations and edits into the system to enable communication/interface between all 
participants via SALTS/Electronic Data Interchange (EDI), and the Military Standard Transaction 
Requisitioning and Issue Procedures (MILSTRIP) via Uniform Inventory Control Program 
(UICP)/Uniform Automated Data Processing (UADPS)/Shipboard Uniform Automated Data 
Processing System (SUADPS) transmissions, so as to maintain status and demand criteria. 


5. To screen out exceptions and queue those items with inadequate data for manual review. 


6. To produce a database of all nonstandard requisitions resident, maintained, updated at the CTA and 
distributed via CD-ROM as part of the Customer and Procurement Activity Modules. 


7. To assure optimum visibility of all nonstandard material buys. 


8. To design a user-friendly, flexible system that will minimize hardware requirements and will meet 
the needs of a broad range of customers. from afloat to ashore. 


9. To develop on-line help, data field validation tests and error correction to assist in document 
preparation. 


10. To develop customer specific guidelines and detailed standardized instructions as to how to use the 
system, how to technical screen items and a decision matrix as to which items will need “deep” 


technical screening, at the customer level and the central site. 


11. To provide on-line technical, relevant Department of Defense information in the form of a quarterly 
newsletter. This will include new instructions, executive orders, etc. 


12. To develop a methodology to systematically update all databases, reference information, etc. that 
reside in the Customer, Procurement Activity and Host modules. 


13. To develop system implementation plans. 


14. To develop contingency plans. 
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CUSTOMER SUPPORT MODULE 


The Customer Support Module resides at the user activity and is the first step in the technical screening 
process. The objectives inherent in the design of this module are as follows: 


I. To design and develop a customer support module, utilizing the electronic nonstandard requisitioning 
document for client-server and stand-alone systems. 


2. To provide in this customer module a nonstandard database that is updated from the CTA via CD- 
ROM. 


3. To allow the customer to automatically “fill out” a requisition (DD Form 1348-6, NAVSUP Form 
1250-2, DD Form 1149 or 80-card column MILSTRIP information), assign a requisition number via 
SUADPS/UADPS and transmit electronically to CTA or Procurement Activity Modules via EDI, 
SALTS. MODEM. 


4. To enable the customer to initially tech screen buys to identify need, gather data via CD-ROM 
nonstandard database, Federal Logistics Information System (FLIS), HAYSTACK, PARTSMASTER. 
etc., identify interchangeable or substitute items and eliminate those non-exigent items which do not 
need to process through central database technical screening (ex: is there a NSN, does it fit the 
purchase card requirements, etc.). These requisitions will bypass the Central Database; however, they 
will be captured in the Demand Recording Document (BHJ) tracking system via Automated 
Procurement and Accounting Data Entry (APADE) suspense files. 


5. To provide as much reference material/instructions (edits) on-line as is feasible to save additional 
hours of searching hardcopy manuals, etc. 


6. To develop on-line help, built-in users’ manual and print down capability. 


7. To develop data field validation tests and error correction to assist in document preparation (for ex. 
Fund code, project code, accounting line data). 


8. To provide a method to configure system to execute (interface/"hotkey’’) other data information 
modules, references, subscriptions. 


9. To give the customer the option to batch process requisitions, using ASCII text files, and/or batch 
modify databases, selecting a field and replacing the values with new data, if this method is feasible. 


10. To establish both automated and manual parameters and procedures for database file maintenance; 
automatically track items in the nonstandard database which were assigned a NSN or a NSN was 
found in the screening process, and remove them from the nonstandard database. 


11. To electronically produce correspondence/forms which relate to the system processes, capture input 
data on these letters/forms, provide the ability for the customer to personalize such correspondence 
and forms (if standardization is not essential), direct to a file and/or transmit via EDI, SALTS, 
MODEM. 


12. To provide the capability to create a system summary of all actions taken during customer screening 
to remain in a history file for a predetermined time. 


13. To build summary transmission of all data input into system and extracted from cognizant databases. 
14. To create a report generator capable of designing customer specific reports for administrative tracking 


and reporting purposes. 
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To empower the customer with the ability to suggest other enhancements, problems with the system. 
via dedicated phone line. which will improve customer support modules and create an efficient. time- 
saving desk top manager, reducing administrative workload. To continue program development as 
the system develops and subsequent to implementation. 


To enable ANSRS participants to input, edit and receive requisitions in MILS-standard format. 


To enable download of data files or requisitioning transactions to floppy discs for transfer to PCs not 
linked to local area network (LAN). 


To screen incoming requisitions for items containing hazardous materials, establishing correct data 
requirements for ordering; determined whether requisitioned item is approved for user activity; 
determine whether requisitioned item is coded for environmental or other special recovery program 
such as the Ozone Depleting Substance (ODS) program; and determine if there are environmentally 
friendly substitutes. 


To provide frequent automatic backup capability to prevent loss of data and/or transactions during 
program use. 


To provide immediate suggestion to originator on where to send requisition for screening and 
procurement, i.e. FISC or CTA. 


To develop approval protocols and security checks for appropriate ordering authorizations to be input 
to database. 


To track transactions, performance of cognizant personnel and pertinent Automated Data Processing 
(ADP) systems through key events in screening and procurement processes. 


To provide retech capability for actions entered erroneously. 


To develop inquiry only option, creating ability to browse database without actually processing a 
requisition. 


To provide capability to archive prior procurement data and build a historical file. 
To provide capability to input nonstandard data or other information which may enhance tech 


screening capability; this includes identification of weapon system application the specific 
procurement is meant to support. 


PROCUREMENT ACTIVITY MODULE 


The Procurement Activity Module will include all the objectives identified in the Customer Module 
(except where they are identified as customer specific objectives) with the addition of the following: 


1. 


To provide a system to the FISC which receives SALTS/EDI transmissions, provides technical 
screening capability at the FISC, provides interface with APADE, and forward transmissio:": to the 
CTA for cases requiring “deep” technical review. 


To enable LAN capability, providing personnel the ability to share and forward case-specific 
information. 
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3. To receive and transmit requisitions and related data via land-based computer networks such as the 
Internet and SLICENET. 


4. To enable development of comprehensive demand database, capturing demand on items bought 
locally by FISCs. 


5. To permit speed routing of requisitions to cognizant material management activity (such as “MD” 
source-coded items which will be made or assembled instead of purchased). 


6. To create FISC-generated BD status in UADPS-SP Requisition Status File (RSF) and provide status 
to customer via AUTODIN. 


7. To provide technical screening status information to customer/CTA. 


8. To feed FISC developed screening data, procurement information and technical screening actions to 
the CTA for central storage and dissemination to other FISCs to preclude duplication of effort, this 
includes periodic reconciliation of FISC and CTA databases. 


9. To forward technical screening data and procurement orders to APADE programs. 
10. To provide capability to receive input transactions in military standard format. 


11. To enable screening personnel to input data into the database. 


HOST MODULE 


The Host/Central Tech Activity Module will include all the objectives identified in the Customer and 
Procurement Activity Modules (except where they are identified as customer or FISC specific objectives) 
with the addition of the following: 


1. To design and develop a Central Database or Host Module capable of accepting EDI, SALTS, 
MODEM transmissions of nonstandard requisitions. This will ensure that all “deep” technical 
screening of nonstandard buys occurs at the central site and is accomplished in a standardized format, 
enabling the central site to maintain an up-to-date technical library, easily accessible to screening 
personnel. 


2. To generate BD status in DSF upon receipt (BO! input to UICP), creates requisition status 
information and provides status to customer via AUTODIN. 


3. To generate BM status in DSF upon referral to APADE (input to UICP), reflects referral of 
procurement package to FISC after tech screening, provides status to customer via AUTODIN. 


4. To generate BV status in DSF upon referral to Integrated Technical Item Management and 
Procurement (ITIMP) (input into UICP), informs customer via AUTODIN that item is being procured 
by NAVICP and will be delivered directly. 


5. To electronically capture APADE data into the BHJ application, matching Allowance Parts List 
(APL) and technical data from ANSRS nonstandard database base on document ID. To assign a 
unique Local Stock Number (LSN). To report the purchase of nonstandard material to 
NAVICP/Integrated Material Manager (IMM) databases, BHJ input to UICP. 
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To maintain status of buys screened and procured by NAVICP-P. To interface with NAVICP-P in the 
distribution of aviation items, status (number of items transmitted to NAVICP-P, data sent, and action 
taken), and update of the nonstandard database. 


To accept technical screening and procurement referrals from the FISCs. 


To correctly prioritize each buy and determine the criticality of trmely processing. A matrix will be 
loaded into the system to automatically determine priority and mission critical elements and a turn 
around time (TAT) will be established based on these elements. 


To define Central Technical Database fields and FLIS information necessary for “deep” tech 
screening. 


To perform “deep” technical screening on those items which were not system compatible subsequent 
to Customer Module. Central Technical Database screening (ex. Items that do not cross to a NSN, 
Hazardous Material items, etc.) 


To perform “deep” technical screening using all available references, technical library material, 
including, but not limited to: Master Item File (MIF), Master Cross Reference List (MCRL), 
historical data, procurement information, Navy Publications, drawings (EDMICS), MIL-SPECS. 
FLIS, FEDLOG, PartsMaster, SNAPSHOT, Inventory Locator Service (ILS), etc. To provide as 
much reference material/instructions on-line as is feasible to save additional hours of searching 
hardcopy manuals, etc., and to provide a method configurable to execute (“hotkey”) other data 
information modules/references/subscriptions. 


To update nonstandard database in ANSRS with predetermined types of items for resubmission to 
Customer/Procurement Activity Support Modules via CD-ROM on a predetermined basis. 


To electronically provide supply options, action posted on requisition, date of action, etc. to all parties 
involved. 


To electronically submit to correct procurement activity and record all actions taken. 
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APPENDIX D: LIST OF SITES IMPLEMENTED 


FISC Jacksonville 
¢ USS GETTYSBURG (CG 64) 
¢ USS PHILIPPINE SEA (CG 58) 


FISC Norfolk 

@ Pierside CEP 170/Q7] 

USS EMORY S LAND (AS 39) 
USS SAIPAN (LHA 2) 

NAS Norfolk 

NAS Willow Grove 


¢¢ ¢ 


FISC Pearl Harbor 

@ FISC Pearl Harbor-Barber’s Point 
USS CUSHING (DD 985) 

USS LAKE CHAMPLAIN (CG 57) 
USS PAUL HAMILTON (DDG 60) 
NAS Barber’s Point 


e¢*?e? ¢ 


FISC Puget Sound 
¢ USS ABRAHAM LINCOLN (CVN 72) 
¢ USS CARL VINSON (CVN 70) 


FISC San Diego 

¢ FISC San Diego-Broadway 
FISC San Diego-Point Loma 
USS MCKEE (AS 41) 

USS SHILOH (CG 67) 

USS TARAWA (AS 41) 


¢?e? ¢ 


FISC Yokosuka 

FISC Yokosuka-Sasebo 

USS BELLEAU WOOD (LHA 2) 
USS RODNEY M DAVIS (FFG 60) 
SRF Yokosuka 

SRF Yokosuka-Sasebo 
COMFELACT Yokosuka 
COMFLEACT Sasebo 
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APPENDIX E: QUESTIONNAIRE 
ANSRS QUESTIONNAIRE 
Note: Some questions may not be pertinent, in entirety or in part, to your job. Please answer as much of 


any question as you can, to the best of your knowledge. If you don’t know part or all of any question, or if 
the question is N/A, say so. 


le Manual Open Purchase Process (Pre-ANSRS, Pre-Credit Card) 
a. Briefly describe the process flow (from end-user to the contracting activity’s customer service 
desk), approximate time involved in each step, the personnel involved in each step, and any 


paperwork or document requirements. 


b. What problems did (do) you encounter with the manual open purchase process? What and 
where in the process were (are) the bottlenecks? 


c. Approximately how long did (does) it take to receive your material this way? 


De IMPAC Credit Card 
a. Doyou currently use the IMPAC credit card? Y N 
b. Ifso, since when? 
c. Describe the workload that was reduced or eliminated. By what percentage? 
d. Describe the workload that was increased or created. By what percentage? 


e. Do you feel that the credit card makes your job easier? Harder? Why? 


2 ANSRS Training 


a. When did you first hear about ANSRS? 


b. What type(s) of training did you receive? Duration? 
None 

Self-training 

lon | 

Group 

Lecture 

Hands-on 

Other (describe) 


Cc. Would you describe the training as good, thorough, and worthwhile? If not, what would 
have helped? 


d. At what point did you understand what ANSRS was intended to do? 


M Pre-training 
M During training 
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@ After working with it 
@ Still somewhat unclear 


e. At what point did you understand how to use ANSRS? 
M@ During training 
M@ After working with it 
@ Still somewhat unclear 


f. How difficult is it for you to adequately train someone within your organization on ANSRS? 
Haven't had to yet 

Not difficult/easy 

Moderately difficult 

Very difficult/hard 

Impossible 


g. How would you improve ANSRS training within your organization? 
h. Do you know where to get assistance within your organization if needed? Y N 
1. Do you know where to get assistance outside your organization if needed? Y N 


j. Do you know how and where to send feedback or suggestions? Y N 


ANSRS Usage 


a. How often do you use ANSRS? 
Daily 

Weekly 

A few times per month 
Rarely 

Never 


b. What do you use ANSRS for? 

NSN screening 

HAZMAT screening 

Mandatory source (NIB/NISH/UNICOR) screening 
Credit card procurements 

Other small purchase procurements 

Large procurements 

Other (describe) 


c. Who uses ANSRS in your organization? 
Commanding Officer 

Executive Officer 

Supply Officer 

HAZMAT Officer 

Storekeepers (how many?) 

RPPOs (how many?) 

Others (describe) 
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Briefly describe the process flow (from end-user to the contracting activity’s customer service 
desk), approximate time involved in each step, the personnel involved in each step, and any 
paperwork or document requirements. 


e. What and where in the process are the bottlenecks? 
f. Approximately how long does it take to receive your material this way? 
g. Does ANSRS decrease your workload (e.g. saves time, saves paperwork)? Y N 
h. If yes. describe how and rank in order of importance to you. 
1. Does ANSRS increase your workload in any area? Y N 
J. If yes, describe how. 
k. What should ANSRS do for you that it cannot now do? 
1. Does your command receive a Non-Standard Data Base (NSDB) update on a regular basis? 
Yea 
m. If yes, how often? 
n. Does ANSRS interface with FEDLOG? Y N 
o. Is ANSRS installed on a LAN within your organization? Y WN 
p. Doyoulike ANSRS? Y N 
Miscellaneous 
a. On average, how many open purchase requisitions do you submit per month for credit card 
purchases? 
@ Less than 6 
@ 6-10 
WM 11-15 
B 16-20 
@ 21-25 
@ More than 25 (how many?) 
b. Non-credit card small purchases? 
@ Less than 3 
@ 3-5 
H 6-10 
@ 11-15 
B 16-20 
@ More than 20 (how many?) 
c. Large purchases? 


eS | 
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m@ 2 
@ 3 
ms 4 
® More than 4 (how many?) 


d. Approximately what percentage of open purchases are for repair parts (vice 
consumables, equipage. services, etc. )? 
@ Credit card 
@ Non-credit card small 
@ Large 
e. Approximately what percentage of open purchases are procured using ANSRS? 
@ Credit card 
@ Non-credit card small 
@ Large 


f. What kinds and how much extra equipage (e.g. terminals) was needed to implement ANSRS 
within your organization? 


5. Additional Comments 


Date ANSRS installed: 

Date ANSRS usage began: 

Rate/rank: 

Position (SUPPO, Leading SK, RPPO, etc.): 

Name/phone number/e-mail/address (optional): 

May I contact you if I have any follow-up questions? Y N 
Would you like a summary copy of the results? Y  N 


THANK YOU!! 


89 


APPENDIX F: TOP REASONS WHY PROCUREMENT DOCUMENTS GET SENT BACK TO 


9, 


SHIPS FROM FISC 
Insufficient description on forms/poor description of competitive items - could be two manufacturers 
with similar items - include size. dimensions, type, etc. for a better description 
Missing, waivers for using mandatory sources 
Missing justification for sole source requests 
Incomplete accounting information - accounting spread, TAC 
Missing justification for ADP/IT requests 


Missing requisition/document numbers - each line item needs a requisition number. APADE specific 
- cannot have one requisition number for 15 line items 


Missing approval signatures 
Missing HAZMAT-related attachments - SHML and MSDS 


Missing GSA contract numbers 


10. Missing IDTC contract numbers 


11. Original equipment manufacturer (OEM) not identified 
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